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A  Communications  Front-End  Processor  (FEP)  was 
implemented  for  a  Digital  Equipment  Corporation  (DEC) 
VAX-11/780  using  a  DEC  LSI-11/23  microcomputer.  The 
LSI-11/23  serviced  eight  DEC  VT-100  terminals  and 
communicated  with  the  VAX-11/780  over  an  Able  Computer 
Technology,  Inc  Direct  Memory  Access  (DMA)  interface.  This 
investigation  proceeded  from  a  FEP  design  provided  in  a 
previous  work  and  culminated  in  the  Telecon  ’  C*  compiler 
language  coding  of  those  design  specifications.  The  design 
was  translated  into  structure  charts  defining  software 
module  functions  and  interfaces.  Program  Design  Language 
(PDL)  was  then  used  to  outline  the  processing  steps  in  a 
structured  programming  format  for  each  software  module.  A 
data  dictionary  was  constructed  to  document  the  data  and 
functional  module  interfaces.  The  code  was  implemented  in  a 
’top-down*  manner. 


CHAPTER  1 
INTRODUCTION 


1 .1  Purpose  - 


The  purpose  of  this  investigation  was  to  design, 
implement,  and  test  software  through  which  a  Digital 
Equipment  Corporation  (DEC)  LSI-1 1/23  microcomputer  could  be 
configured  as  a  Communications  Front-End  Processor  (FEP)  for 
a  DEC  Virtual  Address  Extension  (VAX)-11/780  minicomputer 
within  the  Digital  Engineering  Laboratory  (DEL)  of  the  Air 
Force  Institute  of  Technology  (AFIT).  In  its  FEP 
configuration,  the  LSI-11/23  would  provide  an  interface 
between  the  VAX-11/780  and  the  terminal-related  activities 
of  the  VAX  users. 


The  LSI-11/23  would  service  all  VAX-bound  terminal  I/O 


interrupts,  assembling  the  input  character-by-character 
until  a  complete  command  line  had  been  assembled.  The 
LSI-11/23  would  then  route  this  complete  message  to  the 
VAX-11/780  via  a  high  speed  Direct  Memory  Access  (DMA)  link. 
Return  traffic  to  the  terminal  would  be  handled  in  a  similar 
manner.  The  VAX  response  (character,  line,  page,  or  file) 
would  be  sent  along  the  DMA  to  the  LSI-11/23  which  would 
then  route  it  at  the  proper  terminal  speed  to  the  user  who 
initiated  the  activity.  The  System  Physical  Device  Topology 
is  depicted  in  Figure  1-1. 


1 .2  Background  - 

This  investigation  is  the  logical  continuation  and 
relies  heavily  upon  material  developed  in  a  previous  effort 
[1],  This  previous  investigation  justified  the  FEP  project 
by  establishing  it  as  a  cost-effective  solution  to  the 
resource  saturation  problem  occurring  within  the  DEL 
VAX-11/780.  Resource  saturation  is  the  condition  of  a 
computer  system  when  it  can  no  longer  support  additional 
workload  demands  placed  upon  its  resources  [1:33. 

The  VAX-1 1/780  resource  saturation  condition  was  shown 
[1:163  to  consist  of  three  components:  (1)  Overcrowding  of 


7  VT-100  (  expandable  to  16  ) 

Remote 
Terminals 
(  T1  thru  T7  ) 


T2 


T4  - 


T3 

\ 

\ 

i 

1 

1 

1 

1 

T1 

/ 

/ 

1 

\ 

i 

1 

• 

| 

_  1 

1 

LSI-11/23 

j  _ 

1 

1 

1 

1 

1 

1 

1 

1 

1 

'7 

!  \ 

\' 

/ 

1  \ 

\ 

T5 

!  \ 

T7 

! 

\ 

1 

1 

\ 

T6 

\ 

DMA  Link 


\ 


VAX 

Peripheral 


VAX-1 1/780 


DELNET 


Serial 

Line- 

Printer 


the  VAX  I/O  structure  as  the  number  of  total  system  users 
increased;  (2)  Increased  numbers  of  pending  I/O  requests  as 
the  number  of  concurrent  users  increased;  and,  (3)  Reduced 
central  memory  availability  brought  about  by  the  increased 
number  of  concurrent  system  users.  All  three  components 
were  shown  [1:16-18]  to  be  adequately  addressed  by  the  FEP 
concept . 

A  highly  comprehensive  Requirements  Analysis  was  then 
developed  [1:18-26]  by  considering  (1)  FEP  System  level 
Requirements;  (2)  Hardware  Requirements;  and,  (3)  Software 
Requirements.  This  latter  analysis  was  performed  from  the 
complimentary  and  increasingly  implementation  oriented 
perspectives  of  the  user,  the  network,  and  the  designer.  A 
summary  of  the  culminating  model  -  the  Designer  Perspective 
Software  Sub-System  Requirements  -  appears  in  this  report  as 
Table  1-1.  The  complete  model  is  reproduced  [ 1 : 94  —  112]  in 
this  report  as  Appendix  A. 

1  .3  Problem  Statement  - 

The  problem  pursued  during  this  investigation  was  to 
design,  code,  test,  and  document  the  DEC  LSI-11/23  portion 
of  the  DEL  FEP  network. 


Table  1-1  Designer  Perspective  Software  Requirements 


Requirement 


Description 


1 

1 .1 
1 .2 

1.3 

1 .3.1 

1 .3.1  .1 

1 .3.1 .1 .1 

1 .3.1  .1  .2 

1.3.1 .1 .3 

1 .3.1 .1 .4 
1 .3.1  .2 

1 .3.1  .2.1 
1  .3.1  .2.2 
1 .3.1  .3 
1  .3.1  .3.1 

1 .3.1  .3.2 
1  .3.1  .3.3 
1  .3.1 .3.4 
1  .3.1  .3.5 
1  .3.1  .3.6 
1  .3.2 

1 .3.2.1 

1  .3.2.1 .1 
1 .3.2.1  .2 

1 .3.2.1  .3 
1  .3.2.1  .4 

1 .3.2.2 

1 .3. 2. 2.1 
1  .3  .2.2.2 
1  .3.2.3 
1  .3. 2. 3.1 

1 .3. 2. 3. 2 

1 .3. 2. 3. 3 
1  .3.2. 3. 4 

1 .3. 2. 3. 5 
1  .3. 2. 3. 6 


Local  Computer  Network 
Two  Processors 
Communications  Link 
Software  On  Each  Processor 
Front-End  Software 

Support  User  Terminals 
Virtual  Link 
Information  Routing 
Message  Assembly/Disassembly 
Link  Assignment  Strategy 
Perform  User  Tasks 

Operating  System  Tasks 
Special  Functions 
Comm  Link  Management 
Control  Comm  Link 
Assemble  Comm  Link  Message 
Transmit  Comm  Link  Message 
Receive  Comm  Link  Message 
Disassemble  Comm  Link  Message 
Error  Check  Messages 
Host  Software 

Support  User  Terminals 
Virtual  Link 
Information  Routing 
Message  Assembly/Disassembly 
Link  Assignment  Strategy 
Perform  User  Tasks 

Operating  System  Tasks 
Special  Functions 
Comm  Link  Management 
Control  Comm  Link 
Assemble  Comm  Link  Message 
Transmit  Comm  Link  Message 
Receive  Comm  Link  Message 
Disassemble  Comm  Link  Message 
Error  Check  Messages 


Table  1-1  Designer  Perspective  Software  Requirements  (Cont'd) 


Requirement 


Description 


2 

2.1 

2.2 

2.3 

2.4 


Host  Operating  System 

Multi-Programmed  Environment 
Mass  Storage 
Comm  Link  Support 
High  Level  Language 


3 

3.1 

3.2 

3.3 

3.4 


FEP  Operating  System 

Support  for  Maximum  Terminal  Population 
Mass  Storage 
Comm  Link  Support 
High  Level  Language 


4 

4.1 

4.2 

4.2.1 

4.2.2 

4. 2. 2.1 

4. 2. 2. 2 

4. 2. 2. 3 

4.3 

4.3.1 

4.3.2 

4. 3. 2.1 

4.4 

4.4.1 
4.4.1  .1 
4.4.1  .2 

4.4.1  .3 

4.5 

4.5.1 

4.5.2 


Consistent  User  Interface 

Provide  '’Single  User"  Environment 
Consistent  With  VAX/VMS  Operation 
Single-User/Host  Operations 
Control/Management  Operations 
Terminal  CONNECT 
Terminal  DISCONNECT 
Command  Interpreter 
Procedural  Assistance 

Single-User/Host  Operations 
Control/Management  Operations 
HELP  Operation 
Easy  to  Learn  and  Use 

Control/Management  Operations 
HELP  Operation 
Terminal  CONNECT 
Terminal  DISCONNECT 
Processing  Support  Invisible  to  User 
Single-User/Host  Operations 
Control/Management  Operations 


Table  1-1  Designer  Perspective  Software  Requirements  (Cont'd) 


O 


Requirement 


Description 


5 

5.1 

5.1 .1 

5.1 .2 

5.1 .3 
5.2 
5.2.1 
5.2.1  .1 
5.2.1  .2 
5.2.1  .3 
5.2.1  .3.1 
5.2.1  .3.2 

5.2.1  .3.3 

5.2.2 

5.2.3 

5.2.4 

5. 2. 4.1 

5. 2. 4.1 .1 

5. 2. 4.1  .2 
5. 2. 4.1 .3 

5. 2. 4.1  .4 

5. 2. 4. 2 

5. 2. 4. 2.1 

5. 2. 4. 2. 2 
5. 2. 4. 3 

5. 2. 4. 3.1 

5.2.5 

5. 2. 5.1 

5. 2. 5. 2 


Operating  Environment  Compatibility 
Physical  Plant  Compatibility 
Power  Source 
Temperature  Range 
Humidity  Range 
Academic  Compatibility 
Unattended  Operation 
Startup  Procedure 
Shutdown  Procedure 

Asynchronous  Intermediate  Processing 
User  Level  Messages 
System  Level  Messages 
Queueing  System 

Support  for  8  Interactive  Terminals 
Support  for  Line  Printer 
Support  for  Study  of  LCN 
Collect  Performance  Data 
System  Level  Status 
Terminal  Session  Statistics 
User  Session  Statistics 
System  Queue  Statistics 
File  Transfer 

Transfer  To/From  Host 
Disk  Media 
Peripheral  Sharing 

Route  Output  To  Printer 
DELNET  Integration 

Single-User/DELNET  Operations 
Control/Management  Operations 


£ 


Table  1-1  Designer  Perspective  Software  Requirements  (Cont’d) 


Requirement 

Description 

6 

Supportability 

6.1 

In-House  Maintenance 

6.1  .1 

Hardware 

6.1 .2 

Software 

6.2 

Expansion 

6.2.1 

Modular  Software 

6.2.1 .1 

Functions 

6.2.1  .2 

Functionally  Cohesive 

6.2.1  .3 

Hierarchical  Structur 

6.2.1  .4 

Loosely  Coupled 

6.2.2 

Physical  Configuration 

6. 2. 2.1 

Terminals 

6. 2. 2. 2 

Processors 

6. 2. 2. 3 

Comm  Links 

6.2.3 

Inspect  Configuration 

6.2.4 

Modify  Configuration 

7 

Minimum  Cost 

7.1 

On-hand  Components 

8 

Data  Security 

8.1 

No  Requirement 

.'■v- 

■o.* 


1 .4  Scope  - 


This  effort  was  limited  to  implementing  the  LSI-11/23 

portion  of  the  FEP  for  several  reasons,  among  which  -  time 

constraints,  the  level  of  software  risk,  and  an  expanding 
VAX  configuration  -  were  the  most  crucial. 


It  was  recognized  early  that  the  FEP  system  would  have 
to  operate  effectively  and  dependably  in  a  heavy-use 
environment.  Therefore,  careful  design,  "flawless"  coding, 
and  meticulous  testing  were  mandated  from  the  onset  to 
ensure  a  reliable  product.  To  successfully  implement  the 
FEP,  a  thorough  understanding  would  have  to  be  gained  of  the 
VAX/VMS  operating  system  -  its  services  and  interfaces  as 
well  as  its  capabilities  and  limitations.  A  similarly 
thorough  understanding  would  be  required  of  the  LSI-11/RT-11 
operating  system.  Furthermore,  the  nature  of  the  DMA  link 
would  have  to  be  thoroughly  understood.  As  time  passed,  it 
became  clear  that  the  pursuit  of  this  thorough  understanding 
for  just  one  of  the  computers  could  well  occupy  the 
productive  efforts  of  one  MS  thesis  investigation. 


Software  risk  is  a  measure  (not  always  quantifiable)  of 
the  possible  exposure  to  processing  corruption  introduced  by 
newly  created  software.  The  greatest  risk  applies  to 
long-standing  data  bases  and  library  files  which  would  have 
to  be  re-created  from  dated  checkpoint  files  and,  if 


-  9  - 


•-  •  •*  •  %  •  • .  •  •  *  *  *  *  *  • 


■  •  *  .  • 


possible,  tediously  brought  up-to-date  by  recreating  the 
modifications  which  had  occurred  since  the  last  checkpoint. 
The  DEL  VAX  supports  several  thesis  projects  currently  in 
progress  and  departmental  Data  Base  classes.  Conversely, 
there  are  no  users  requiring  the  dedicated  use  of  the  DEL 
LSI-11/23.  For  the  few  users  who  do  have  occasion  to  use 
the  DEL  LSI-11/23,  the  possiblity  of  cross-contamination  of 
user  files  is  non-existant  because  each  user  reboots  the 
system  at  the  start  of  a  user  session  and  physically  removes 
their  diskettes  at  the  termination  of  their  session.  While 
the  LSI-11/23  FEP  implementation  bears  the  lesser  risk,  its 
realization  will  benefit  the  riskier  VAX  implementation  by 
providing  a  driver/debugger  capability  during  the  VAX  FEP 
development  effort. 

The  final  major  reason  for  targeting  the  LSI-11/23  as 
the  initial  FEP  implementation  was  the  configuration 
upgrades  that  were  occurring  for  the  VAX.  These  upgrades 
included  both  hardware  and  software  and  would  have 
transformed  what  was  to  have  been  a  risky  software 
development  effort  into  a  possible  perilous  effort.  These 
upgrades  are  projected  to  taper  off  with  time  -  thereby 
restoring  a  degree  of  stability  to  the  VAX-11/780  FEP 
development  environment. 


1 .5  Approach  - 


The  Software  Engineering  techniques  that  were  used 
throughout  this  effort  can  be  classified  as  "top-down”  and 
"structured".  Both  of  these  techniques  have  proven  to  be 
useful  [25]  during  the  Software  Development  Life  Cycle  of  a 
project.  Development  tools  and  documentation  aids  used 
throughout  this  effort  include  "Structure  Charts"  (  ref 
Appendix  B  ) ,  a  "Data  Dictionary"  (  ref  Appendix  C  ) ,  and 
Program  Design  Language  (PDL). 


1.5.1  Software- Deyeloomen.t  -Life  Cycle 


To  better  control  the  development  of  a  project, 
software  managers  have  identified  six  separate  stages 
through  which  software  projects  pass;  these  stages  are 
collectively  called  the  Software  Development  Life  Cycle 
[25:198]: 

1 .  Requirements  Analysis 

2.  Specification 

3.  Design 

4.  Coding 

5.  Testing 

6.  Operation  and  Maintenance 


1.5. 1.1  Requirements  Analysis  -  The  Requirements  Analysis 
focuses  on  the  interface  between  the  computer,  used  as  a 


tool  to  solve  some  problem,  and  the  people  who  need  to  use 
it.  A  Requirements  Analysis  can  aid  in  understanding  both 


the  problem  and  the  tradeoffs  among  conflicting  constraints, 
thereby  contributing  to  the  best  solution  [25:199]. 

1.5. 1.2  Specification  -  While  Requirements  Analysis  seeks 
to  determine  whether  to  use  a  computer,  Specification  seeks 
to  define  precisely  what  the  computer  is  to  do,  but  not  how 
to  do  it.  Issues  that  are  examined  at  this  stage  include 
input  and  output  record  formats,  database  layouts,  algorithm 
selections,  etc  [25:199]. 

1.5. 1.3  Design  -  In  the  Design  stage,  the  algorithms 
called  for  in  the  Specifications  are  developed,  and  the 
overall  structure  of  the  computer  system  takes  shape.  The 
system  is  divided  into  small  parts  (modules)  with 
constraints  as  to  function,  size,  and  speed  [25:200], 

1  .5.1.4  Coding  -  Coding  is  usually  the  easiest  stage. 
High-level  languages  and  structured  programming  simplify  the 
task.  In  one  study,  Boehm  [26]  found  that  64?  of  all  errors 
occurred  in  design,  but  only  36%  in  coding.  Hamilton  and 
Zeldin  [27]  report  that  in  the  NASA  Apollo  project  about  73% 
of  all  errors  were  design  errors.  It  appears  that  coding 
has  been  mastered  better  than  any  other  stage  of  software 
development  [25:200]. 

1.5. 1.5  Testing  -  The  testing  stage  may  require  up  to  half 
of  the  total  development  effort.  Testing  is  divided  into 
three  distinct  operations:  1)  "Module  Testing"  subjects 


each  module  to  the  test  data  supplied  by  the  programmer; 
2)  "Integration  Testing"  tests  groups  of  components 
together;  and  3)  "Systems  Testing"  involves  the  test  of  the 
completed  system  by  an  outside  group  [25:2003. 

1  .5.1.6  Operation  and  Maintenance  -  These  first  five 
stages,  collectively  forming  the  development  activities, 
account  for  only  25?  to  33?  of  the  total  effort  required 
during  the  life  of  the  system  [25:201].  Maintenance  costs 
ultimately  dwarf  development  costs. 

It  should  be  clear  that  each  software  development  stage 
may  influence  earlier  stages.  The  writing  of  specifications 
gives  feedback  for  evaluating  resource  requirements;  the 
design  often  reveals  flaws  in  these  specifications;  coding, 
testing,  and  operation  reveal  problems  in  design  [25:2023. 

It  should  also  become  obvious  that  the  particular  stage 
at  which  an  error  is  detected  directly  effects  the  cost  of 
correcting  that  error.  Modifications  made  to  the  project 
have  a  "rippling"  effect  that  propogates  in  both  directions 
from  the  point  of  change.  For  instance,  customer 
dissatisfaction  with  a  test  result  could  evolve  because  the 


requirements 

analysis 

did 

not 

precisely 

describe 

the 

customer’s  desires. 

In 

effect 

,  the  wrong 

problem 

was 

solved.  If 

this  flaw 

were 

discovered 

during 

the 

Specification 

stage, 

the 

cost 

of  modification  would 

be 

considerably  less  than  it  is  after  coding  has  been 
completed . 


The  Software  Engineering  Techniques  used  in  developing 
the  software  system  included  Top-Down  Design,  Top-Down 
Development,  and  Structured  Programming. 


1 .5.2.1  Top-Down  Design  -  Top-down  design  is  a  technique 
in  which  a  programmer  first  formulates  a  subroutine  as  a 
single  statement,  which  is  then  expanded  into  one  or  two  of 
the  basic  control  structures  discussed  in  paragraph  1.5. 2. 3 
(Structured  Programming).  At  each  level,  the  function  is 
expanded  in  increasingly  greater  detail  until  the  resulting 
description  becomes  the  actual  source  language  program. 
Using  this  approach,  also  called  "stepwise  refinement",  the 
program  is  hierarchically  structured  and  is  described  by 
successive  refinements  [25:211], 


1.5 .2. 2  Top-Down  Development  -  This  is  another  technique 
for  implementing  hierarchically  structured  programs.  Here 
the  top-level  routines  are  written  first,  and  the  lower 
level  routines,  called  stubs,  are  written  to  interface  with 
these.  The  stubs  return  control  after  printing  a  simple 
message  and  may  return  some  fixed  test  value.  The  stub  is 
eventually  replaced  by  the  full  module  which  would  then 
include  calls  to  other  stubs.  In  this  manner,  an  entire 


system  can  be  gradually  developed  and  tested  [25:212] 


1  .5.2.3  Structured  Programming  -  A  major  development  in 
facilitating  the  programming  task  is  known  as  "structured 
programming".  The  premise  here  is  to  use  a  small  set  of 
simple  control  and  data  structures.  A  program  then  is  built 
by  nesting  these  statements  inside  each  other.  This  method 
restricts  the  number  of  connections  between  program  parts 
and  thereby  improves  the  comprehensibility  and  reliability 
of  the  program.  The  "if-then-else" ,  "while-do",  and 
"sequence"  statements  are  one  commonly  suggested  set  of 
control  statements  for  this  type  of  programming  [25:211], 

1.5.3  Development  Tools  and  Documentation  Aids  - 

Three  Development  Tools  and  Documentation  aids  were 
chosen  from  among  the  many  currently  available.  Selection 
criteria  included  a)  clarity  of  presentation,  b)  user 
familiarity,  c)  ease  of  modification,  and  d)  availability  of 
automated  storage  and  retrieval. 

Structure  Charts  were  chosen  over  Structured  Analysis 
and  Design  Technique  (SADT)  diagrams  because  they  were  rated 
higher  in  "module  communication",  "training  need",  and 
"proliferation"  [28:68].  Likewise,  Data  Dictionary  entries 
were  chosen  over  other  database  structure  representation 
tools  such  as  Data  Structure  Diagrams  due  to  the  higher 
degree  of  maintainability  and  clarity  of  expression 


[28:72-89]  provided  with  a  data  dictionary.  PDL 
(pseudocode)  was  chosen  to  represent  software  behavior 
instead  of  techniques  such  as  flow  charts  to  take  advantage 
of  PDL’s  clarity  characteristics  of  explicitly  representing 
control  structure  and  nesting  level  depictions. 

1 .5.3.1  Structure  Charts.  -  Structure  Charts  (  ref 
Appendix  B  )  provide  a  visible  and  convenient  method  for 
portraying  the  interrelationships  between  the  individual 
software  modules.  Hierarchical  and  scope  of  control 
relationships  can  be  easily  seen.  Also,  parameter  passing, 
in  the  form  of  data  and  control  flags,  between  modules  can 
be  effectively  identified. 

1  .5.3.2  Data  Dictionary  -  A  Data  Dictionary  (  ref  Apper.nx 
C  )  is  a  document  in  which  the  names t  attributes,  and 
relationships  of  software  data  items  and  functional  modules 
can  be  described.  It  serves  as  a  cross-reference  locator 
for  the  various  constants,  variables,  and  procedures 
appearing  throughout  the  source  listings.  The  functional 
module  entries  contain  a  Program  Design  Language  (PDL) 
summary  of  the  software  logic. 

1 .5.3.3  Program  Design  Language  (PDL)  -  PDL  (  ref  Appendix 
C  )  is  a  type  of  language  which  contains  two  structures: 
"outer"  syntax  of  the  basic  control  statements  (  ref  para 
1  .5.2.3)  and  an  "inner"  syntax  that  corresponds  to  the 


application  being  designed.  The  inner  syntax  is  English 
statement  oriented,  and  is  expanded,  step  by  step,  until  it 
expresses  the  algorithm  in  some  programming  language 
[25:212] . 


1  .6 


Overview  Of  Thesis  - 


This  thesis  concentrates  upon  the  software  design  and 
implementation  of  a  previously  specified  FEP  [1]  system. 
The  Requirements  Analysis  was  accomplished  in  this  previous 
effort  and  is  summerized  in  this  report  in  Chapter  2. 
Chapter  2  also  describes  several  System  Design  Decisions 
made  during  the  course  of  this  current  investigation.  Next, 
the  Network  Design  and  Protocol  Issues  are  discussed 
(Chapter  3).  The  thesis  continues  with  the  Software  Design 
and  Implementation  (Chapter  4),  the  Software  Test  and 
Evaluation  (Chapter  5),  and  the  Conclusion  (Chapter  6). 


Appendices  include  the  Software  Requirements  Analysis 
(Appendix  A),  LSI  FEP  Structure  Charts  (Appendix  B) ,  LSI  FEP 
Data  Dictionary  (Appendix  C),  LSI  FEP  Source  Code  Listings 
(Appendix  D),  LSI  FEP  Memory  Load  Map  (Appendix  E),  LSI  FEP 
User's  Guide  (Appendix  F),  and  LSI  FEP  Programmer's  Guide 
(Appendix  G) . 


CHAPTER  2 

REQUIREMENTS  ANALYSIS  AND  DESIGN  DECISIONS 


In  this  chapter,  the  top  level  "System  Level 
Requirements"  [1:15-263  are  examined  and  then  prioritized 
for  implementation.  It  is  from  this  basic  requirements 
definition  and  the  step-wise  decomposition  of  these 
requirements  that  the  final  "Designer  Perspective  Software 
Requirements"  (Appendix  A)  was  created.  Design  Decisions 
and  Trade-offs  are  then  examined  and  justified. 

This  chapter  also  discusses  the  capabilities  and 
limitations  of  the  LSI-11/23  microcomputer  hardware  and 
software  in  addressing  the  LSI  FEP  requirements.  This 
chapter  (along  with  Chapter  3)  describes  the  decisions  made 
during  the  first  3  Software  Development  Life  Cycle 
[  para  1.5.1  3  stages  (Requirements  Analysis,  Specification, 
and  Design)  of  this  software  project. 


2.1  System  Level  Requirements 


The  problem  previously  investigated  [1:5]  involved 
resolution  of  the  VAX  resource  saturation  condition.  To 
solve  that  problem,  eight  subordinate  requirements  [1:18] 
were  identified  : 

1.  Local  Computer  Network  (LCN) 

2.  Host  (VAX)  Operating  System 

3.  FEP  (LSI)  Operating  System 

4.  Consistent  User  Interface 

5.  Operating  Environment  Compatibility 

6.  Supportability 

7.  Minimum  Cost 

8.  Data  Security 

These  System  Level  Requirements  and  their  decomposed 
sub-groupings  are  discussed  in  the  following  paragraphs. 
The  numbers  within  the  parentheses  refer  to  the  system 
requirements  depicted  in  Table  2-1 . 

2.1.1  Local  Computer  Network  - 

The  FEP  topology  specified  a  local  computer  network 
(LCN)  (1)  connecting  two  processors  (1.1)  with  a 
communications  link  (1.2).  Network  software  (1.3)  would  be 
required  for  both  processors  [1:18-21], 

2.1.2  Host  Operating  System.  - 


Functions  required  of  the  VAX  operating  system  include 
capabilities  for  supporting  a  multi-programmed  environment 


Table  2-1 


System  Level  Requirements 


Requirement 

Description 

1 

1 .1 

1  .2 

1.3 

Local  Computer  Network 

Two  Processors 

Communications  Link 

Software  On  Each  Processor 

2 

2.1 

2.2 

2.3 

2.4 

Host  Operating  System 

Multi-Programmed  Environment 

Mass  Storage 

Coram  Link  Support 

High  Level  Language 

3 

3.1 

3.2 

3.3 

3.4 

FEP  Operating  System 

Support  for  Maximum  Terminal  Population 

Mass  Storage 

Comm  Link  Support 

High  Level  Language 

4 

4.1 

4.2 

4.3 

4.4 

4.5 

Consistent  User  Interface 

Provide  "Single  User"  Environment 

Consistent  With  VAX/VMS  Operation 

Procedural  Assistance 

Easy  to  Learn  and  Use 

Processing  Support  Invisible  to  User 

5 

5.1 

5.1  .1 

5.1  .2 

5.1  .3 

5.2 

5.2.1 

5.2.2 

5.2.3 

5.2.4 

5.2.5 

Operating  Environment  Compatibility 

Physical  Plant  Compatibility 

Power  Source 

Temperature  Range 

Humidity  Range 

Academic  Compatibility 

Unattended  Operation 

Support  for  7  Interactive  Terminals 

Support  for  Line  Printer 

Support  for  Study  of  LCN 

DELNET  Integration 

6 

6.1 

6.2 

6.2.1 

6.2.2 

Supportability 

In-House  Maintenance 

Expansion 

Modular  Software 

Physical  Configuration 

7 

7.1 

Minimum  Cost 

On-hand  Components 

(2.1),  at  least  one  mass  storage  device  (2.2),  the  DMA  comm 
link  (2.3),  and  the  high  level  language  (2.4)  selected  for 
the  software  implementation  [1:21-22], 


Functions  required  of  the  LSI  operating  system  Include 
capabilities  for  supporting  a  multi-terminal  environment 
(3.1),  at  least  one  mass  storage  device  (3.2),  the  DMA  comm 
link  (3.3),  and  the  high  level  language  (3.4)  selected  for 
the  software  implementation  [1:22-23]. 


2.1  .4 


This  requirement  serves  to  minimize  the  amount  of 
"re-learning"  required  by  the  VAX  user  to  access  the  VAX 
through  the  LSI  FEP.  Specific  functions  include  providing 
all  concurrent  users  with  the  full  spectrum  of  VAX 
capabilities  available  to  a  single  user  (4.1)  connected 
directly  to  the  VAX.  Furthermore,  any  special  procedures 
necessary  to  operate  the  FEP  system  must  be  consistent  with 
the  VAX/VMS  functional  interface  (4.2),  and  a  method  of 
obtaining  assistance  (4.3)  on  the  procedures  should  be 
provided.  Finally,  the  user  interface  must-  be  easy  to  learn 
and  use  (4.4)  and  the  processing  necessary  to  support  it 
should  be  virtually  invisible  (4.5)  to  the  user  [1:23]. 


Physical  plant  corapatability  (5.1)  requires  the  FEP  to 
function  within  the  power  (5.1.1),  temperature  (5.1.2),  and 


humidity  (5.1.3)  ranges  existing  within  the  DEL.  Academic 
compatability  (5.2)  requires  the  FEP  to  run  unattended 
(5.2.1)  while  supporting  eight  (expandable  to  16) 
concurrent,  interactive  user  terminals  (5.2.2)  and  at  least 
one  line  printer  (5.2.3).  As  a  teaching  tool,  the  FEP 
should  support  the  study  of  the  LCN  environment  (5.2.4). 
Finally,  the  FEP  must  be  capable  of  full  integration  (5.2.5) 
into  the  Digital  Engineering  Laboratory  Network  (DELNET) 
[1:243. 

2.1.6  Supportabllltv.  - 

In-house  maintenance  (6.1),  using  DEL  resources,  is 
required  for  hardware  and  software  components.  Potential 
system  expansion  (6.2)  of  the  physical  configuration  (6.2.1) 
as  well  as  individual  software  modules  (6.2.2)  requires  the 
flexibility  provided  by  current  software  engineering 
practices  [1:24-253. 

2.1.7  Minimum  Cost.  - 

This  requirement  implies  the  selection,  whenever 
possible,  of  network  hardware/software  components  already 
on-hand  (7.1)  or  readily  available  to  the  DEL  [1:253. 


No  specific  requirements  were  listed  under  this  topic 
[1:25].  Furthermore,  since  VAX  processing  of  classified 
information  was  not  expected  to  occur,  then  this  System 
Level  Requirement  (Requirement  8  in  Table  I)  was  eliminated 
from  Table  2-1 . 


2.2  Requirements  Prioritization  - 

The  possibility  of  not  implementing  the  entire  FEP 
system  during  the  course  of  one  thesis  effort  was  recognized 
as  a  highly  probable  event.  Therefore,  a  priority  ranking 
of  the  System  Level  Requirements  was  accomplished  to 
establish  an  implementation  ordering.  This  section  contains 
these  priority  decisions  which  directly  drove  the  software 
design  and  coding  efforts. 

Those  requirements  which  were  constraints  included: 

a.  Most  of  the  Local  Computer  Network  (1)  — -  the  lone 
exception  being  the  degree  of  sophistication  of  the 
Software  on  Each  Processor  (1.3), 

b.  The  Physical  Plant  Compatability  (5.1)  portion  of 
the  Operating  Environment  Compatability  (5), 

c.  The  In-House  Maintenance  (6.1)  portion  of 
Supportability  (6)  , 


d.  The  Minimum  Cost  (7) 


Other  requirements  identified  capabilities  already  in 
existance  within  the  VAX/VMS  and  LSI/RT-11  operating 
systems.  These  included: 

a.  The  Host  Operating  System  (2) 

b.  The  FEP  Operating  System  (3) 

These  observations  left  the  following  areas  in  which 
prioritization  ranking  could  occur: 

a.  The  Software  on  Each  Processor  (1.3)  portion  of 
Local  Computer  Network  (1), 

b.  Consistent  User  Interface  (4), 

c.  The  Academic  Compatability  (5.2)  portion  of 

Operating  Environment  Compatability  (5), 

d.  The  Expansion  (6.2)  portion  of  Supportability  (6). 

2.2.1  Top  Priority.  - 

The  first  priority  decision  made  was  in  the  area  of 
Processor  Software  (1.3).  It  was  decided  to  concentrate  the 
efforts  of  this  thesis  on  implementing  the  LSI  portion  of 
the  FEP  system  requirements  (  ref  para  1 .4  ) .  Host  network 
software  would  be  limited  to  a  driver/debugger  application 
program  to  manage  the  DMA  traffic  at  the  VAX  end  of  the 
communications  link.  This  program  would  initiate  DMA 


transfers,  respond  to  incoming  comm  link  traffic,  and 
display  the  comm  link  traffic  upon  a  VT-100  interactive 
terminal . 

2.2.2  High.  Priority.  - 

Certain  requirements  were  viewed  as  absolutely 
necessary  —  either  from  a  network  point-of-view  or  from  an 
operator  point-of-view.  Requirements  designated  as 

essential  fell  into  one  of  two  categories  : 

a.  If  the  requirement  was  a  specific  function,  then  it 
was  implemented  before  any  lower  priority  function, 

b.  If  the  requirement  described  a  design  strategy, 
then  it  served  as  a  design  guideline  and  molded 
follow-on  design  decisions. 

Requirements  identified  as  high  priority  include: 

2. 2. 2.1  Provide  Single-User  Environment.  -  Of  all  the 
System  Level  Requirements,  this  one  most  closely  relates  to 
the  overall  reason  for  the  FEP  concept  - —  namely  to  solve 
the  VAX  resource  saturation  problem.  This  requirement 
basically  means  that  each  concurrent  user  will  experience  an 
environment  in  which  they  could  imagine  that  they  were  the 
sole  user  connected  directly  to  the  VAX.  Implied  within 
this  definition  are  several  important  concepts: 

A.  Reliable  Terrainal/Process  linkage  in  both 

directions.  This  requires  the  FEP  software  to 
communicate  the  terminal  requests  to  the  proper 


process  executing  on  the  host  and  to  return  the 
proper,  uncontaminated  response  from  the  host  to 
the  appropriate  terminal. 

B.  Terminal  response  delay  should  not  be  noticably 
longer  during  FEP  operations  than  the  delay  which 
could  reasonably  be  expected  to  occur  during 
single-user  operation.  This  requires  fast 
executing  code  and  rapid  movement  of  data. 

C.  The  full  repertoire  of  VAX/VMS  commands  must  be 
available  to  each  concurrent  user  without  adding 
any  FEP-unique  command  overhead  to  his  use  of  the 
FEP.  This  implies  a  processing  transparency 
requirement  for  the  LSI  FEP  software. 


2. 2. 2. 2  Consistent  With  VAX/VMS  Operation.  -  This  function 
implies  that  all  services  normally  provided  by  the  host's 
terminal  device  drivers  must  now  be  provided  within  the  LSI 
FEP  so  that  the  VAX/VMS  would  be  presented  with  a  Consistent 
User  Interface. 

2. 2. 2. 3  Unattended  Operation.  -  Since  the  host  VAX 
operates  in  an  unattended  configuration,  its  LSI  FEP 
extension  should  be  designed  to  not  require  any  additional 
manning  overhead. 

2. 2. 2. 4  Support  for  7  Interactive  Terminals.  -  Support  for 
8  Interactive  Terminals  (  ref  para  2.1.5  )  could  not  be  met 
due  to  system  limitations.  The  LSI-11/23  hardware 
components  reside  within  a  Plessey  Peripheral  Systems 
MICRO-II  based  computer  system  [2:1-33.  The  Plessey 
PM-MFV11A  Multifunction  board  provides  four  Electronic 
Industry  Association  (EIA)  RS232  ports  which  may  be  used  for 


console  device  interface,  printer,  modem,  or  spare  terminals 
[3:1-1].  Port  1  is  permanently  assigned  to  the  console, 
leaving  only  3  ports  on  the  PM-MFV1 1 A  card  for  spare 
terminals.  A  DLV11-J  card  was  inserted  into  the  LSI-11  bus 
to  provide  4  additional  asynchronous  serial  interfaces 
(ports)  to  the  FEP.  These  two  cards  provide  a  total  of  only 
7  (not  8)  interactive  terminal  interfaces.  Therefore, 
requirement  5.2.2  (Table  2-1)  was  changed  to  reflect  the 
current  physical  limitation  of  Support  for  7  Interactive 
Terminals . 

[  NOTE:  Although  not  designed  for  this 
purpose,  the  console  can  be  used  as  the  eighth 
terminal  and  software  support  for  this 
contingency  was  written.  However,  all  LSI  FEP 
system  error  and  status  messages  will  be  output 
to  the  console  screen.  This  could  become  quite 
annoying  to  an  interactive  user  stationed  at 
this  console.] 

2.2.3  Medium  PriPrjLSy*  - 

Assigned  to  this  category  were  functions  which  were 
desirable  for  early  implementation,  but  not  required  for  the 
basic  FEP  to  operate.  These  functions  could  have  been 
deferred  for  implementation  in  a  follow-on  thesis 
investigation  if  time  ran  out  during  the  current  thesis 
effort.  Medium  priority  functions  include: 


that  the  user  not  be  burdened  with  additional  operating 
overhead  in  order  to  communicate  his  requests  to  the  VAX. 
This  requirement  is  consistent  with  the  high  priority 
requirement  to  Provide  a  "single-user”  Environment  (  ref 
para  2. 2. 2.1  ).  With  the  successful  implementation  of  this 
high  priority  requirement,  it  is  expected  that  a  minimum 
operating  overhead  will  fall  out  as  an  inevitable 
by-product . 


2. 2. 3. 2  Processing.  Support  Invisible  to  the  User.  -  This 
requirement  specifies  that  the  user  need  not  know  where, 
within  the  network,  his  requests  are  processed.  It  is 
absolutely  transparent  (and  of  no  importance)  to  him  that 
terminal  device  driver/interrupt  service  functions,  for 
example,  have  been  removed  from  the  VAX  processor  to  the 
LSI-11/23  processor.  As  with  the  previous  medium  priority 
requirement,  it  is  expected  that  Invisible  Support  to  the 
User  will  be  satisfied  during  implementation  of  the  high 
priority  Provide  a  "Single-User"  Environment  requirement. 

2. 2 .3. 3  Support  for  LCN  Study  -  This  requirement  specifies 
the  periodic  trapping  of  system  queueing  data  for  later, 
off-line  reduction  and  analysis.  Although  providing  a 


significant  opportunity  to  monitor  network  status  in  a 
dynamic  environment,  this  requirement's  implementation  is 
not  essential  for  the  FEP  system  to  function. 


2.2.3  "  Expansion .  -  This  requirement,  which  is  decomposed 
into  Modular  Software  and  Physical  Configuration  specifies  a 
flexible  implementation  which  would  easily  accomodate  system 
modifications  such  as  the  addition  of  more  terminals  or 
software  function/subroutines.  This  requirement  was 
assigned  a  medium  priority  primarily  because  it’s 
implementation  conflicts,  at  times,  with  that  of  the  higher 
priority  requirements.  For  instance,  modular  software 
engineering  practices  encourage  a  minimum  of  data-structure 
sharing  between  software  modules.  This  concept  requires 
each  module  to  define  the  data  items  and  structures  that 
will  be  required  during  its  execution.  On  the  LSI-11/23 
these  locally  defined  data  items  are  created  each  time  the 
subroutine  is  called  and  destroyed  each  time  the  subroutine 
exits.  Although  well-designed  from  a  software  engineering 
perspective,  this  repeated  creation  and  destruction  of  the 
same  data  definitions  is  counter-productive  in  a  real-time, 
interrupt-driven  application.  The  additional  processing 
overhead  required  to  isolate  modular  data  creates  an 
unacceptable  delay  in  the  network  processing,  especially 
those  functions  that  service  interrupts.  For  these  reasons, 
the  Expansion  requirement  has  been  assigned  a  medium 
priority  so  that  implementation  conflicts  may  be  resolved  in 
favor  of  the  higher  priority  tasks. 
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Requirements  assigned  in  this  category  include  those 
which  are  desirable,  but  less  important  than  even  the  medium 
priority  tasks.  Included  within  this  category  are: 

2. 2. 4.1  Procedural  Assistance.  -  This  function  specifies 
the  need  for  "HELP"  commands  to  be  made  available  for  the 
user  to  operate  the  network.  It  is  envisioned  that,  if  the 
requirements  for  "Single-User"  Environment  (  ref  para 

2. 2. 2.1  )  and  Easy  to  Learn  and  Use  (  ref  para  2. 2. 3.1  ) 
have  been  properly  implemented,  then  the  requirement  for  a 
"HELP"  file  will  be  near  non-existent.  Therefore,  a 
decision  as  to  the  need  for  its  implementation  should  be 
deferred  until  after  the  other  two  requirements  have  been 
implemented. 

2. 2. 4. 2  Support  for  On-Line  Printer.  -  This  requirement, 
part  of  the  original  network  design  [1:35],  specified  a 
serial  line  printer  to  be  connected  to  the  LSI.  However, 
the  current  effort  is  directed  at  implementing  the  basic  FEP 
system  and  then  enhancing  it  as  resources  permit.  Under 
this  concept,  moving  the  printer  from  the  VAX  to  the  LSI 
becomes  an  enhancement  rather  than  a  high  priority 
requirement.  The  driving  goal  during  the  early 
implementation  stages  is  to  free  the  VAX  of  the  interactive 
I/O  overhead  by  relocating  the  terminal  device 


driver/ interrupt  routines  to  the  LSI.  To  move  the  printer 
functions  concurrently  would  be  to  expose  the  initial  FEP 
implementation  to  a  higher  risk  factor  than  is  clearly 
warranted  at  this  early  stage.  Delaying  the  printer 
relocation  will  also  simplify  the  test  and  evaluation  stage 
of  the  initial  implementation. 

2. 2. 4. 3  DELNET  Integration.  -  This  function  pre-  supposes 
the  existance  of  the  DELNET.  Pending  the  implementation  of 
the  DELNET,  this  requirement  will  be  assigned  a  low  priority 
status . 


2.3  Design  Decisions  And  Tradeoffs  - 

Several  situations  requiring  major  design  decision 
trade-offs  were  encountered  during  this  investigation. 
These  were  considered  "major"  design  decision  trade-offs 
because  their  resolution  affected  and  guided  further  design 
issues.  Throughout  the  FEP  effort,  additional  "minor" 
trade-off  decisions  were  made  which  influenced  the 
implementation  of  specific  functions  (  i.e.  size  of  buffers 
and  headers,  etc.).  Discussion  of  these  "minor"  issues  is 
deferred  until  the  functions  themselves  are  discussed. 
These  "major"  issues  are  discussed  in  the  following 


paragraphs 


y. 


2.3.1 


This  is  a  familiar  trade-off  decision  often  faced  by 
the  application  programmer.  In  most  applications,  a  program 
can  be  made  to  execute  faster  only  at  the  expense  of 
increased  memory  requirements.  Likewise,  memory  may  often 
be  saved  by  recoding  the  program  to  execute  slower.  Rarely 
will  a  programmer  be  able  to  concurrently  optimize  both 
program  parameters. 


The  FEP  system  is  no  different  than  most  real-time 
applications.  It  was  expected  to  function  in  a  dynamic 
environment,  servicing  a  variable  number  of  randomly 
arriving  "bursty"  terminal  requests.  This  environment  would 
be  best  served  with  a  fast  executing  program  which  would 
minimize  the  chance  for  FEP  saturation  (and  its  resulting 
loss  of  data)  when  the  system  was  pushed  to  its  maximum 
activity  levels. 


Supporting  this  "speed"  over  "size"  decision  was  the 
availability  of  the  RT-11  Extended  Memory  (XM)  Monitor 
C7:4.1].  The  XM  monitor  provides  a  usable  memory  capacity 
four  times  that  of  the  standard  RT-11  Single  Job  (SJ) 
Monitor  [7:4.63.  Paragraph  2.3.7  describes  how  the  RT-11 
monitor  was  to  be  utilized. 


-  32  - 


•’  •’  V*  *  V  *  .  *»  -  * 


•.*  ,  *.  *,  *.  N  JN  ,*  ,*»  *'•  ,*  .■*  ,  ’  .  *  * 

*  •  *.*  «*  •’  \  «*.  »’.  •  »  *  »•  i.*  c'  c.*  OO 


It  was  recognized  early  that  all  incoming  data  traffic 
to  the  LSI-11/23  would  have  to  be  serviced  by  honoring  an 
I/O  interrupt.  This  was  required  because  the  LSI  uses  a 
single  memory  location,  the  Receive  Data  Buffer  (RBUF),  for 
receipt  of  character  data.  Ensuing  characters  will 
over-write  the  previous  character  regardless  of  whether  that 
previous  character  has  been  retrieved  by  an  application  or 
systems  program.  If  the  RBUF  for  each  terminal  was  serviced 
synchronously,  then  valuable  processing  time  could  be  wasted 
checking  ports  at  which  no  new  data  had  arrived  since  the 
prior  servicing. 

On  the  other  hand,  interrupt-driven  Input  servers  would 
only  execute  when  needed  and  could  be  constructed  to  contain 
the  minimum  amount  of  processing  needed  to  fetch  the 
character,  store  it  away,  and  perform  mimimal  immediate 

response  for  a  select  subset  (  i.e.  -  backspace,  carriage 

return,  control-C,  etc.)  of  the  possible  character  set. 

Similar  reasoning  would  seem  to  have  advocated  an 
interrupt-driven  output  server  as  well.  However,  three 
important  considerations  suggested  synchronous  servicing  of 
output  character  traffic  as  a  better  approach. 

a.  Although  the  receipt  of  input  data  was  random  in 
nature,  the  output  of  data  traffic  would  be  totally 
under  program  control. 


b.  Like  the  RBUF,  the  Transmit  Data  Buffer  (XBUF) 

could  be  overwritten  with  ensuing  characters  if  the 
serial  interface  was  not  provided  a  sufficient  time 
interval  during  which  it  could  transfer  the 

previous  character. 

c.  It  was  considered  highly  likely  that  incoming  data 
interrupts  could  occur  while  the  LSI  was  busy 
executing  an  output  interrupt  routine. 

This  last  concern  presented  two  possible  treatments: 

a.  Disable  interrupts  while  processing  an  interrupt. 

b.  Allow  nesting  of  interrupts. 

Both  approaches  presented  drawbacks.  Locking  out 
interrupts  would  present  a  high  probability  for  lost  data 
because  the  RBUF  of  a  fast  keyboard  typist  could  be 
overwritten  before  the  LSI  was  notified  of  a  new  character’s 
presence  there.  Nesting  of  interrupts  would  slow  down  the 
processing  due  to  the  overhead  involved  in  storing  and 
retrieving  register  information  required  for  the  orderly 
resumption  of  an  interrupted  routine.  Nesting  of  interrupts 
would  also  require  the  additional  overhead  of  designing, 
coding,  and  testing  re-entrant  subroutines. 

Both  of  these  problems  can  be  avoided  by  implementing  a 
synchronous  servicing  discipline  for  outbound  characters 
from  the  LSI.  A  polling  method  could  be  implemented  in 
which  the  Transmit  Ready  bit  in  the  Transmitter  Control  and 
Status  Register  (XCSR)  would  be  interrogated  prior  to  the 


program  moving  the  next  character  into  the  XBUF.  This  bit 
is  set  by  the  hardware  when  the  serial  interface  is  ready  to 
accept  the  next  character  [20:507].  Usually,  polling  would 
consist  of  the  software  executing  a  tight  loop  until  the  bit 
was  set.  For  the  FEP  system,  any  loop  idling  for  indefinite 
time  durations  would  have  to  be  minimized.  Conveniently, 
however,  at  least  one  indefinite  loop  is  mandated  for  the 
system.  This  loop  is  the  large  idle-loop  that  encompasses 
all  non-interrupt  processing  functions.  This  loop  will  be 
entered  after  system  initialization  and  iterate  continuously 
until  the  system  is  terminated.  The  polling  routines  were 
selected  for  inclusion  within  this  large  loop. 

If  the  Transmit  Ready  bit  in  XCSR  was  set  when  checked, 
then  the  next  output  character  would  be  moved  to  XBUF.  If 
the  bit  were  not  set,  then  the  next  synchronous  task  would 
be  executed  and  a  recheck  of  XCSR  would  be  delayed  until  the 
next  pass  through  the  loop.  Since  most  iterations  of  the 
large  loop  would  not  find  new  work,  it  was  projected  that 
this  scheme  would  introduce  very  little  additional  delay  in 
the  movement  of  output  characters  to  the  target  device.  On 
the  other  hand,  all  XCSR/XBUF  pairs  could  be  interrogated 
within  the  same  loop,  thus  economizing  the  wait  process  when 
output  data  was  available  for  more  than  one  device. 


Device  Handlers  (drivers)  are  routines  that  provide  the 
interface  to  the  computer  hardware  devices.  The  handlers 
drive,  or  service,  peripheral  devices  and  manage  information 
transfer  between  memory  and  the  devices  [7:2.193.  Device 
handlers  are  usually  stand-alone  programs  which  must  be 
loaded  into  physical  memory  before  they  can  be  used.  An 
interrupt  service  routine,  on  the  other  hand,  is  coded  as  an 
integral  part  of  the  application  program.  This  routine  is 
called  by  the  main  program  to  initiate  an  I/O  transfer.  The 
routine  then  returns  execution  control  back  to  the 

application  program  until  the  transfer  is  complete  -  at 

which  time  the  device  issues  an  interrupt.  This  interrupt 
forces  a  transfer  of  execution  control  back  to  the  interrupt 
service  routine  which  can  then  take  appropriate  action 
(restart  the  I/O  transfer,  return  to  the  program,  or 
possibly  retry  the  transfer  in  case  of  an  error)  [7:6.2]. 

The  major  advantages  in  using  Device  Drivers  are  that  they: 

A.  Provide  device  independence  for  the  application 
program 

B.  Can  share  processor  time  with  other  processes 

C.  Are  simple  to  use 

The  major  advantages  in  using  In-line  Interrupt  Service 


Routines  are  : 


A.  Their  speed  of  execution 

B.  The  amount  of  control  information  they  provide 

Device  independence  was  never  a  design  consideration 
because  DEC  VT-IOO’s  were  specified  [1:3*1]  as  the 
interactive  terminal  devices.  Since  no  other  process  was 
expected  to  be  simultaneously  executing  on  the  LSI-11/23, 
there  was  no  requirement  to  ensure  process-sharing  of 
resources.  Simplicity  of  use  was  not,  by  itself,  sufficient 
justification  for  using  Device  Drivers.  On  the  other  hand, 
speed  of  execution  was  a  critical  component  for  real-time 
applications  and  supported  the  high  priority  requirement  to 
"Provide  a  ’Single-User1  Environment"  discussed  previously 
(  ref  para  2.2.2.1.B  ).  Providing  additional  control 
information  was  a  benefit  whose  implementation  cost  was 
negligible.  Therefore,  the  third  "major"  design  decision 
was  to  implement  In-Line  Interrupt  Service  Routines  rather 
that  Device  Handlers. 

2.3.4  D.evlce  Priority.  - 

Specifying  the  device  priorities  amounts  to  determining 
the  servicing  order  when  simultaneous  interrupts  occur. 
Although  the  LSI-11/23  allows  four  interrupt  levels,  it  was 
decided  not  to  utilize  this  feature  due  to  the  interrupt 
nesting  problems  that  could  occur  [  20:178-180  and 


para  2.3.2  ].  Instead,  device  card  placement  on  the  LSI 
UNIBUS  would  be  used  to  enforce  device  priority.  When 
devices  of  equal  priority  level  request  an  interrupt, 
priority  is  given  to  the  device  electrically  closest  to  the 
processor  [20:350].  Since  the  overall  goal  of  the  FEP  is  to 
reduce  the  VAX  workload,  then  DMA  traffic  could  not  be 
allowed  to  back-up  within  the  host.  Therefore,  the  DMA 
device  was  selected  as  the  highest  priority  device,  the 
terminals  next,  and  the  System  Operator  Console  (SOC)  last. 

However,  system  constraints  prevented  this  exact 
ordering  from  being  implemented.  The  UNIBUS  is  contained 
within  the  Plessey  chassis.  The  Plessey  orders  the 
priorities  of  the  9-slot  UNIBUS  backplane  slightly 
differently.  The  PM-MFV11A  multifunction  board  is  allocated 
first  priority  before  any  other  cards.  This  means  that  the 
System  Operator’s  Console  (SOC)  port  and  the  other  3  serial 
I/O  ports  on  that  card  will  have  a  higher  interrupt  priority 
than  the  DMA  card.  The  4  port  serial  I/O  interface  card, 
DLV11-J,  will  still  be  inserted  further  away  from  the 
processor  than  the  DMA  card.  Those  software  functions  whose 
servicing  order  is  arbitrary  will  be  coded  to  discriminate 
in  favor  of  rapid  movement  of  DMA  traffic.  (These  and  other 
items  of  Software  Design  are  discussed  in  Chapter  4)  . 
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Mapping  is  the  process  of  associating  Virtual  Addresses 
with  Physical  memory  locations  [7:4.18].  A  Virtual  Address 
is  a  value  in  the  range  of  0  through  177777  (octal).  It  is 
a  16-bit  address  within  a  program’s  32K-word  address  space 

-  created  at  assembly  time  and  modified  during  the  linking 

process.  A  Physical  Address  is  the  actual  hardware  address 
of  a  specific  memory  location.  In  the  RT-11  Extended  Memory 
(XM)  environment,  Physical  Addresses  lie  in  the  range  0 
through  777777  (octal)  because  the  XM  Memory  Management  Unit 
(MMU)  appends  two  additional  high  order  bits  to  the  16-bit 
Virtual  Address  to  create  a  Physical  Address  space  of  128K 
words . 

Virtual  Mapped  jobs  load  into  memory  at  offset  500 
(octal)  from  the  start  of  the  user  address  space  [7:4.26]. 
Since  all  jobs  can  only  access  memory  addresses  within  their 
user  address  space,  virtual  jobs  cannot  access  addresses  0 
through  477  (octal).  Privilege  Mapped  jobs  load  into  memory 
at  offset  0  and  can  access  all  of  memory  [7:4.271.  Physical 
Addresses  60  through  477  (octal)  are  used  by  the  RT-11 
monitor  for  interrupt  vector  linkages.  These  vectors  are 
loaded  with  the  addresses  of  the  interrupt  service  routines 
which  are  to  assume  execution  control  upon  device  issuance 
of  an  I/O  interrupt. 


A” 
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Since  a  previous  design  decision  (  ref  para  2.3.3  ) 
indicated  the  preference  for  In-line  Interrupt  Service 
Routines  over  Device  Handlers,  it  becomes  necessary  to  be 
able  to  access  these  interrupt  vectors  and  load  them  with 
vector  information.  Since  Virtual  Mapping  cannot  access 
these  locations,  Privileged  Mapping  is  required. 

A  memory  load  map  of  the  final  LSIFEP  program  mapping 
is  included  as  Appendix  E. 

2.3.6  Processor  Transition  to  System  State.  - 

The  XM  monitor  can  support  multiple  programs,  although 
only  one  can  be  actively  using  the  processor  at  any  given 
time.  The  non-active  jobs  may  have  been  placed  in  their 
current  wait  state  for  various  reasons:  blocked  awaiting 
I/O  completion,  pre-empted  by  a  higher  priority  job, 
hybernating  for  a  pre-determined  period,  etc. 

When  the  RT-11  scheduler  commands  the  processor  to  run 
a  different  job,  the  monitor  executes  a  Context  Switch 
[7:3.233.  Context  switching  is  the  procedure  through  which 
the  monitor  save’s  a  job’s  context  -  its  machine  environment 
and  important  job-specific  information  -  and  begins 
execution  of  another  job. 

The  following  information  is  saved  in  a  context  switch 
[7:3.291: 
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a.  Processor  Status  Word  (PS) 

b.  Program  Counter  (PC) 

c.  Stack  Pointer  (SP) 

d.  Registers  RO  through  R5 

e.  Kernal  Page  Address  Register  #1  (PARI) 

f.  Memory  Management  fault  trap  vector 

g.  Break  Point  Trap  (BPT)  vector 

h.  Input/Output  Trap  (IOT)  vector 

i.  TRAP  vector 

j.  System  Communication  Area  (locations  40-52) 

k.  Floating  Point  Processor  (FPP)  registers 

l.  FPP  status  word 

m.  Stack 

n.  Impure  data  area 

Applications  programs  execute  in  User  State,  during 
which  time  Context  Switching  is  enabled.  However,  the 
monitor  forces  a  transition  to  System  State  whenever  it 
determines  that  a  potential  Context  Switch  must  be  delayed. 
Typically,  these  situations  occur  when  the  monitor  is 
executing  and  is  modifying  important  data  structures.  The 
System  State  ensures  that  no  other  application  program  can 
interrupt  the  monitor,  gain  execution  control  of  the 
processor,  and  contaminate  the  data  structure  modification 
process  before  it  has  completed  [7:3.24], 


Any  I/O  interrupt  issued  while  the  system  is  in  System 
State  will  be  delayed  until  User  State  is  re-entered.  This 
could  present  serious  consequences  for  the  FEP  system.  The 
VAX-to-LSI  DMA  transfer  would  function  as  a  high  bandwidth 
input  from  an  independent  source.  It  is  conceivable  that 
data  could  be  lost  and  error  conditions  not  be  recognized 
immediately  if  these  interrupts  are  delayed  for  too  great  a 
period  of  time.  For  this  reason,  it  is  imperative  to  limit 
the  number  of  transitions  to  System  State  as  well  as  the 
duration  of  those  System  State  processes  which  come  under 
programmer  control.  These  include  certain  types  of  I/O 
transfers,  programmed  requests  (.PROTECT,  .CHCOPY,  .INTEN, 
etc.),  and  XM  mapping  requests  issued  from  within  the 
program  [7:3.24]. 

2.3.7  RT-11  Extended  Memory  (XM)  Utilization.  - 

Low  Memory  is  the  physical  memory  between  0  and  28K 
words  (addresses  0  to  177777).  Extended  Memory  is  the 
physical  memory  above  the  28K  word  boundary  (addresses 
200000  to  757777)  [7:4.1].  The  topmost  4K  words  (addresses 
760000  to  777777)  form  the  1/0  Page  and  are  reserved  by  the 
operating  system  for  register  usage  and  1/0  transactions. 
Portions  of  the  FEP  software  reside  in  Low  Memory  along  with 
all  of  the  RT-11  XM  Monitor  software.  Other  portions  of  the 
FEP  software  are  mapped  to  Extended  Memory  with  the  aid  of 
the  Memory  Management  Unit  (MMU)  [7:4.8], 
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There  are  two  ways  [7:4.4]  to  map  portions  of  a  program 
to  Extended  Memory.  One  is  by  issuing  XM  programmed 
requests  from  within  the  program  itself.  The  other  way  is 
to  generate  the  entire  executable  program  image  at  link  time 
by  explicitly  directing  the  linker  to  map  specific  segments 
to  Low  Memory  and  others  to  Extended  Memory  [9:11.4],  This 
latter  approach  was  selected  because  it  allowed  more 
flexibility  and  speed  of  change  when  such  changes  were 
required  in  the  mapping  assignments.  Furthermore,  this 
decision  supports  the  need  to  limit  the  number  of  programmed 
requests  (  ref  para  2.3.6  )  issued  by  the  LSI  FEP 
application  software. 

Certain  constraints  are  forced  upon  the  mapping  process 
by  the  LSI  hardware  and  software  architectures  [7:4.8]: 

a.  Interrupt  service  routines  must  be  located  entirely 
within  the  low  28K  words  of  memory. 

b.  Interrupt  service  routines  must  neither  reside  in 
nor  reference  addresses  within  the  range  of  20000 
through  37777. 

With  these  restrictions  in  mind,  all  software 
processing  logic  for  the  LSI  FEP  was  intended  to  reside  in 
Low  Memory.  All  buffers  of  significant  size  would  have  been 
allocated  to  Extended  Memory.  This  isolation  of  data  from 
instructions  would  have  allowed  independent  "tweaking"  of 
either  without  causing  massive  readjustments  in  the  other  to 


accomodate  the  change 


However,  during  early  implementation  and  testing, 
another  (undocumented)  constraint  was  discovered  which 
precluded  this  assignment  scheme.  Apparently,  in  addition 
to  residing  entirely  within  low  memory,  an  interrupt  service 
routine  can  only  reference  data  locations  within  lower 
memory.  Attempts  to  write  to  buffer  areas  in  extended 
memory  from  within  low  memory  interrupt  service  routines 
resulted  in  low  memory  instructions  being  overwritten  with 
data . 


Since  these  buffer  areas  had  to  be  allocated  to  low 
memory,  a  real  dilemma  developed  as  to  exactly  which  program 
functions  could  be  removed  to  extended  memory.  The  final 
discriminant  was  whether  the  function  could  potentially  be 
called  by  an  interrupt  service  routine.  The  eventual  memory 
assignment  strategy  is  discussed  in  Chapter  4. 

2.3.8  High  Level  Language  Selection.  - 

Two  high  level  languages  were  implemented  for  use  on 
the  LSI-11/23  in  the  DEL:  NBS  Pascal  and  TELECON  »C*.  One 
inherent  limitation  with  Pascal  is  that  address  selection  is 
accomplished  by  defining  pointers  over  whose  values  the 
programmer  had  no  control.  Also,  the  setting  of  interrupt 
vectors  would  be  impossible  in  NBS  Pascal  because  the 
address  of  the  vector  could  not  be  specified  by  the 


programmer.  A  third  NBS  Pascal  limitation  is  that  the 
address  of  a  subroutine  could  not  be  fetched  or  moved. 

These  limitations  could  be  circumvented  by  implementing 
these  critical  functions  at  the  assembly  language  level,  but 
this  approach  would  detract  from  the  high  maintainability 
and  expandability  requirements  already  specified  (  ref  para 
2.1.6  ).  The  'C*  programming  language  [21,  22]  possessed 
none  of  these  limitations.  Therefore,  it  was  chosen  as  the 
implementaion  language  for  the  LSI  FEP. 

Although  another  *  C *  compiler  product  was  available 
from  Whitesmiths  [29,  30],  it  had  not  been  received  by  the 
DEL  prior  to  the  implementation  phase  of  this  investigation. 
For  this  reason,  the  Telecon  1 C *  compiler  was  chosen  for 
source  program  compilation. 


2.4  Summary  - 

This  chapter  described  the  system  level  requirements 
for  the  LSI  FEP.  It  then  prioritized  these  requirements  to 
facilitate  an  orderly  design  and  coding  phase.  These 
priority  categories  included  top  priority,  high  priority, 
medium  priority,  and  low  priority.  The  chapter  concluded 
with  an  examination  of  the  design  decisions  and  trade-offs 


v.v 


which  occurred  due  to  conflicting  constraints  and  LSI-11/23 

capability  (or  inability)  to  adequately  address  the  system 
requirements. 


;-v-: 


-  46  - 


-V  . 


CHAPTER  3 

NETWORK  DESIGN  AND  PROTOCOL  ISSUES 


This  chapter  describes  the  design  of  the  communication 
network.  In  order  to  clarify  and  resolve  the  network 
issues,  the  system  topology  will  be  studied  from  a  network 
node  perspective  rather  than  from  the  physical  device 
perspective  of  Figure  1-1.  These  issues  are  discussed  in 
terms  of  physical  and  logical  nodes,  which  are  defined  and 
then  identified.  The  chapter  then  continues  with  a 
presentation  of  the  protocol  requirements  at  the  various 
network  layers.  The  FEP  System  Network  Node  Topology  is 
contained  in  Figure  3-1 . 

3.1  Logically  Connected  Nodes  - 

This  type  of  node  represents  a  software  module  which 
executes  as  an  autonomous,  specialized  function  within  the 


NODES: 


1.  LSI  System  Manager  (LSM) 

2.  LSI  Terminal  Manager  (LTM) 

3.  LSI  Link  Manager  (LLM) 

4.  LSI  Printer  Manager  (LPM) 

5.  VAX  Link  Manager  ( VLM) 

6.  VAX  Process  Manager  (VPM) 

7.  VAX  System  Manager  (VSM) 


Figure  3-1  System  Network  Node  Topology 


d 


network.  Data  is  moved  between  logical  nodes  using  a  packet 
switched  [5:116]  concept.  Seven  nodes  were  identified: 

3.1.1  LSI. , System..  Mapgflsr  1LSM2  - 

LSM  Executes  the  interrupt  routines  and  other  functions 
to  manage  the  LSI  System  Operator’s  Console  (SOC)  through 

which  is  exercised  operator  control  over  the  LSI  system. 

The  LSM  controls  the  SOC/LSI  interface. 

3.1.2  LSI  Terminal.  Manager  (LTM)  - 

LTM  Executes  the  interrupt  routines  and  other  functions 
to  manage  the  seven  User  Terminals  (T1  -  T7) .  The  LTM 

controls  the  TTx/LSI  interface. 

3.1.3  LSI  Link  Manager  (LUO.  - 

LLM  Executes  the  interrupt  routines  and  other  functions 
to  manage  the  LSI  end  of  the  LSI/VAX  interface. 

3.1.4  LSI  Printer  Manager  LLEiQ  - 

LPM  Executes  the  interrupt  routines  and  other  functions 
to  manage  the  LSI  Serial  Line  Printer  (SLP).  The  LPM 

controls  the  SLP/LSI  interface. 
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VLM  Executes  the  interrupt  routines  and  other  functions 


to  manage  the  VAX  end  of  the  LSI/VAX  interface. 

3.1.6  VAX  Process  Manager  (VPM)  - 

VPM  Executes  all  functions  required  to  interface 
DMA-delivered  traffic  with  the  VAX/VMS  Process  Management, 
Memory  Management,  and  other  system  functions.  The  VPM  is 
the  only  logical  node  which  does  not  service  an  I/O  device. 

3.1.7  VAX  System  Manager  (VSM)  - 

VSM  Executes  the  interrupt  routines  and  other  functions 
to  manage  the  VAX  System  Operator's  Console  (SOC)  through 
which  is  exercised  operator  control  over  the  VAX  system. 
The  VSM  controls  the  SOC/VAX  interface. 


3.2  Physically  Connected  Nodes  - 


Physically  connected  nodes  are  logical  nodes  which  are 
connected  to  each  other  by  means  of  a  physical  data  link  of 
some  type.  The  possible  data  links  include:  a)  Serial;  b) 
Parallel;  and  c)  DMA  links.  No  requirements  have  been 
defined  for  parallel  data  transfers  within  the  FEP  system. 


The  physical  data  paths  within  the  FEP  system  include: 
a)  Peripheral/LSI  interface;  b)  LSI/VAX  interface;  and  c) 
Peripheral/VAX  interface.  Of  these  three,  only  the  LSI/VAX 
interface  connects  logical  nodes  (LLM  and  VLM)  at  both  ends. 
Therefore,  these  two  nodes  are  the  only  physically  connected 
nodes  in  the  system. 


3.3  Protocol  Layers  - 

The  discussion  of  protocol  layers  begins  at  the  lowest 
(Physical)  level  and  progresses  upward  using  the  ISO 
Reference  Model  [5:15].  This  model  is  included  as  Figure 
3-2.  The  network  issues  at  each  level  are  examined  and 
applied  to  the  FEP/VAX  environment. 

3.3.1  Physical  (Laver  1)  - 

Issues  normally  addressed  at  the  Physical  level  include 
Multiplexing  [5:1033,  Terminal  Concentration  [5:122],  Packet 
Assembly/Disassembly  [5:122],  and  Error  Control  [5:125-132]. 

3 .3. 1.1  Terminal  Multiplexing  -  Terminal  Multiplexing 
involves  using  a  device  (terminal  controller)  that  accepts 
input  from  a  collection  of  lines  in  some  static, 
predetermined  sequence  and  outputs  the  data  onto  a  single 
output  line  (the  DMA  link)  in  the  same  sequence.  Each 
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terminal  device  is  assigned  a  time  slot  in  which  only  its 
traffic  may  be  transmitted  along  the  output  line.  This 
output  line  must  have  the  same  transmission  capacity  as  the 
sum  of  the  input  line  capacities  because  each  terminal  may 
have  data  to  transmit  when  its  time  slot  is  serviced.  When 
a  terminal  has  no  data  to  transmit,  the  output  line 
transmits  dummy  fill  characters  during  that  terminal's  time 
slot. 


The  big  disadvantage  of  Time  Division  Multiplexing 
(TDM)  is  that  when  a  terminal  has  no  traffic,  then  its  time 
slot  is  wasted.  It  is  not  possible  to  simply  fill  in  the 
unused  time  slot  with  data  from  another  terminal  because 
both  sender  and  receiver  are  synchronized  as  to  when  a 
specific  terminal's  time  slot  occurs.  No  mechanism  exists 
to  key  the  receiver  that  the  agreed  upon  position  sequencing 
of  terminals  has  changed  without  resynching  the  two  ends. 
If  each  terminal  has  traffic  only  a  small  fraction  of  the 
time,  then  TDM  makes  inefficient  use  of  the  output  line 
capacity  [5:121]. 

3. 3. 1.2  Terminal  Concentration  -  When  the  actual  traffic 
is  far  below  the  potential  traffic,  most  of  the  time  slots 
on  the  output  line  are  wasted.  Consequently,  it  is  often 
possible  to  use  an  output  line  whose  transmission  capacity 
is  less  than  the  sum  of  the  input  line  capacities.  This 
arrangement  is  called  Concentration.  The  usual  approach  is 


to  only  transmit  actual  data  and  not  dummy  fill  characters. 
However,  this  strategy  introduces  two  new  problems. 

The  first  problem  is  keying  the  receiver  as  to  which 
characters  came  from  which  input  line  [5:122],  To  solve 
this  problem,  the  string  of  characters  from  each  terminal  is 
arranged  into  a  message  to  which  is  appended  a  message 
header  prior  to  its  release  to  the  output  line.  This 
message  header  contains  (among  other  fields)  the  terminal 
identification  of  the  sender. 

^he  other  problem  is  tied  to  the  smaller  line  capacity 
of  the  output  line.  If  each  terminal  suddenly  starts 
outputting  data  at  its  maximum  rate,  inadequate  output  line 
capacity  exists  to  handle  the  deluge  and  some  data  may  be 
lost.  For  this  reason,  concentrators  are  always  provided 
with  extra  data  buffers  in  order  to  survive  short  data 
surges  [5:122].  The  more  memory  (larger  the  buffers)  that  a 
concentrator  has,  the  more  it  costs,  but  the  more  likely  it 
is  to  survive  the  short  data  surges.  Choosing  the 
appropriate  parameters  for  output  line  bandwidth  and 
concentrator  memory  size  involves  trade-offs.  If  either  is 
too  small,  data  may  be  lost.  If  either  is  too  large,  then 
the  entire  arrangement  may  be  unnecessarily  expensive. 
Furthermore,  the  optimum  choices  depend  upon  the  traffic 
statistics,  which  are  not  always  known  at  system  design  time 


The  FEP  system  will  provide  Terminal  Concentration  at 
the  LTM  node  by  merging  the  asynchronous  serial  inputs  from 
the  seven  user  terminals  into  a  single  data  flow  to  the  LLM 
node.  Although  traffic  statistics  are  not  known  at  this 
time,  the  DMA  transmission  rate  is  known  to  be  as  high  as 
125000  words  per  second  up  to  lengths  of  50  feet  [18:2.1], 

3.3.1  .3  Packet  Assembly/Disassemblv  -  Packet 
Assembly/Disassembly  (PAD)  was  renamed  Command  Completion 
Sensing  PAD  and  is  deferred  treatment  until  the  Transport 
Layer  Protocol  discussion  (paragraph  3. 3. 4. 6). 

3-3-1  .4  Error  Control  -  Most  Error  Control  at  the  Physical 
level  is  realized  in  hardware.  Since  plans  do  not  exist  to 
add  hardware  components,  Error  Control  will  be  deferred 
treatment  until  the  Data  Link  Layer  discussion  (  ref  para 

3. 3. 2.1  ). 

3.3.2  Data  Link  (Laver  2)  - 

Typical  issues  at  this  level  include  Frame  Control 
[5:137],  Buffering  and  Flow  Control  [5:143],  Sequence 
Numbering  [5:146],  and  Error  Control  [5:164],  The  only 
node-to-node  path  along  which  data  transverses  a  physical 
data  link  is  at  the  LLM/VLM  interface.  Therefore,  the  data 
link  protocol  will  only  apply  to  that  interface.  The 
primary  network  effect  characterizing  this  level  is  the 
electrical  noise  in  the  physical  medium.  Resolution  of 


several  Data  Link  issues  normally  requires  the  construction 
of  a  Data  Link  Frame  Header  (DLFH).  Figure  3-3  contains  the 
format  for  the  FEP  DLFH. 

3. 3. 2.1  Error  Control  -  Error  Control,  deferred  from  the 
Physical  level  (para  3. 3. 3. 4),  is  provided  by  placing  a 
checksum  within  the  Data  Link  Frame  Header  (DLFH).  The 
receiving  node  verifies  this  checksum  with  an  independent 
one  which  it  calculates  itself.  If  the  checksums  verify, 
then  the  receive  node  "piggy-backs"  an  acknowledgement  (ACK) 
back  to  the  sending  node  in  the  DLFH  of  the  next  reverse 
direction  message  frame.  If  reverse  traffic  does  not  occur 
prior  to  a  timeout  period,  then  the  ACK  is  sent  as  a  new 
packet.  If  the  checksums  do  not  verify,  then  an  immediate 
NAK  is  sent  to  the  sender  who  responds  by  retransmitting  the 
frame. 

3. 3. 2. 2  Frame  Control  -  An  ACK/NAK  timeout  is  used  to 
ensure  positive  receipt  of  the  message  frame.  Automatic 
retransmission  occurs  for  the  frame  currently  outstanding  if 
the  ACK/NAK  timer  expires  prior  to  some  acknowledgement  of 
receipt  from  the  receiver. 

3. 3. 2. 3  Buffer  and  Flow  Control  -  The  DMA  channel  could 
become  a  bottleneck  in  the  system.  Therefore,  adequate 
Buffering  and  Flow  Control  mechanisms  must  be  used.  This  is 
true  for  both  ends,  but  is  most  critical  at  the  LLM  (LSI) 
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Figure  3-3  Data  Link  Frame  Header  (DLFH) 


end  because  file  transfers  from  the  VAX  could  conceivably 
saturate  the  LSI  node.  To  provide  Flow  Control,  a  "throttle 
bit"  is  provided  within  the  DLFH.  By  this  method,  the  LLM 
could  ACK  the  last  frame  (and  there-by  inhibit  a 
retransmission)  but  still  alert  the  VLM  to  stop  transmitting 
until  the  ACK  was  repeated  with  the  "throttle  bit"  turned 
off. 


3. 3. 2. 4  Sequence  Numbering  -  At  times,  the  situation  may 
occur  in  which  the  receiver  acknowledges  receipt  of  a 
message,  but  an  electrically  noisy  medium  damages  (or  loses) 
that  acknowledgement  (ACK).  According  to  para  3. 3. 2. 2,  the 
currently  outstanding  frame  would  be  retransmitted  when  its 
ACK/NAK  timer  expired.  The  receiver  would  then  receive  a 
duplicate  frame  of  the  one  it  had  just  acknowledged.  To 
preclude  the  receiver  from  again  processing  this  message 
request  a  sequence  number  is  included  in  the  DLFH 
(  fig  3-3  ) •  The  transmitter  increments  this  number  for 
each  newly  created  message  frame.  The  receiver  ACKs  each 
frame  it  receives  but  only  processes  messages  containing  new 
sequence  numbers. 
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3.3.3  Network  (Laver  3)  - 

Typical  issues  at  this  level  include  Error  and  Sequence 
Control  C5:190],  Routing  [5:196-214],  Buffering  and 
Congestion  Control  [5:215-225],  and  Accounting.  The  network 
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is  passing  data  "packets”  between  logical  nodes  at  this 
level. 

-  V 

3. 3. 3.1  Error  Control  -  Error  Control,  at  this  level,  only 
applies  to  delayed  packets  because  most  data  transfers 
between  logical  nodes  occur  within  the  same  machine  (VAX  or 
LSI).  This  packet  passing  consists  of  passed  parameters  and 
common  buffers  between  called  subroutines.  Therefore,  in 
the  absence  of  an  electrically  noisy  medium,  traditional 
issues  of  lost,  damaged,  or  duplicate  packets  are  not  a 
problem  at  this  level. 

3. 3. 3. 2  Sequence  Control  -  Sequence  Numbering  is  deferred 
to  the  Transport  layer  (para  3. 3. 4. 5). 

0  3. 3. 3. 3  Buffering,  and.  -Congestion  ggp.tr.pl  -  Congestion 

Control  is  provided  by  implementing  interface  Buffers 
between  each  pair  of  logically  connected  nodes.  Four 
pointers  (  LOW,  PUT,  GET,  HIGH  )  are  defined  for  each 
buffer.  LOW  and  HIGH  define  the  physical  limits  of  the 
buffer  in  memory  and  never  change.  The  Sending  node  writes 
to  the  buffer  and  adjusts  the  PUT  pointer.  The  receiving 
node  reads  the  buffer  and  adjusts  the  GET  pointer.  If 
sufficient  room  does  not  exist  within  the  buffer  for  the 
packet  in  hand,  then  the  sending  node  throttles  itself  and 
checks  again  later.  This  ensures  that  no  logical  node  is 
sent  data  for  which  it  does  not  have  sufficient  buffer  space 
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Although  circular  buffering  was  preferred,  system 
limitations  required  that  flat  buffering  be  used  in  the 
final  implementation.  This  limitation  revolved  around  the 
DMA  hardware  which  incremented  an  addressing  register 
[18:4-91  to  point  to  the  next  word  for  data  transfer.  This 
circuitry  could  not  be  programmed  to  account  for  buffer 
"wrap-around"  situations.  Thus,  all  data  words  constituting 
a  single  message  were  constrained  to  be  stored  in  contiguous 
memory  locations. 

3.3 .3.4  Routing  -  Since  a  unique  path  exists  between  each 
user  (LSI)  and  process  (VAX)  pair,  alternate  routing  is  not 
a  consideration.  Once  the  LSI's  terminal  ID  (TID)  and  the 
VAX's  process  ID  (PID)  have  been  established,  the  virtual 
circuit  (parts,  of  which,  are  shared  by  other  virtual 
circuits)  will  be  known  and  remain  static  throughout  the 
terminal  session. 

3. 3. 3. 5  Accounting  -  Accounting  statistics  are  maintained 
for  queueing  and  computer  performance  evaluation  studies. 
Statistics  are  updated  each  time  that  a  change  in  queue 
status  occurs.  These  updated  statistics  are  spooled  out  to 
disk  for  off-line  data  reduction  and  analysis. 


Issues  at  this  level  include  Addressing  and  Connection 
[5:325-338],  Flow  Control  [5:338-343],  Process  Multiplexing 
[5:343-345],  Error  Control  [6],  Sequencing  and  Segmentation 
[6],  and  Command  Completion  Sensing  PAD,  which  was  deferred 
from  the  Physical  Layer  (  ref  para  3. 3. 1.3  ).  Similar  to 
the  Data  Link  Frame  Header  (  ref  para  3.3.2  ),  a  Transport 
Header  (  ref  Fig  3-4  )  is  required  to  resolve  issues  at  this 
level . 

3. 3. 4.1  Address  and  Connection  -  Connection/Termination  at 
the  Transport  level  consists  of  the  "LOGON"  and  "LOGOFF" 
requests  and  VAX  responses.  Within  each  Transport  Header 
(  ref  Fig  3-4  )  is  a  field  set  aside  for  Terminal  ID.  The 
Terminal  ID  (one  of  8  possible  values  representing  one  of 
the  8  peripherals  attached  to  the  LSI)  also  constitutes  the 
Circuit  ID  in  a  one-to-one  mapping. 

The  Transport  Header  (  ref  Fig  3-4  )  also  contains  a 
Node  Identification  field.  This  Node  ID  indicates  from 
which  node  queue  the  message  originated.  The  primary 
purpose  of  the  Node  Id  is  to  tag  the  Accounting  data  so  that 
queueing  statistics  can  be  calculated. 

3 .3 .4 .2  Flow  Control  -  Flow  Control  and  Buffering 
techniques  are  the  same  at  this  level  as  those  employed  at 
the  Network  level  (  ref  para  3. 3. 3. 3  ).  Maximum  buffer  size 


sVvvVxV 


!  I  1 

i  :  a  : 

i  i  i 

!  1  ! 

1 

B  !  C 

i 

i 

-  1 

1 

1 

1 

1 

I 

1 

1 

D  ! 

1 

1 

1 

-  -  -  -  1 

E 

i 

t 

i 

!  LEGENE 

i 

1 

field 

,  , 

: 

name 

bytes 

ref: 

A 

Terminal  ID 

3 

para.  3.3. 

4.1 

B 

Terminal  Mode 

1 

para.  3.3. 

4.6 

C 

Sequence  Number 

4 

para.  3.3. 

4.5 

D 

Character  Count 

4 

para.  3.3. 

4.5 

E 

Originating  Node 

3 

para.  3.3. 

4.1 

Figure  3-4  Transport  Header 


will  be  initially  set  at  2000  characters  and  adjusted,  if 
required,  during  the  implementation  and  testing  stages  when 
empirical  data  becomes  available. 

3. 3. 4.3  Process  Multiplexing  -  Upward  Multiplexing  is  used 
within  the  VPM  node  to  transfer  the  terminal  requests  to  the 
proper  VAX/VMS  process.  In  this  scheme,  multiple  Transport 
connections  (VT-100  terminals)  all  use  the  same  virtual 
circuit  (DMA)  to  the  host. 

3. 3. 4. 4  Error  Control  -  Error  Control  is  not  required  at 
this  level  due  to  the  method  of  internally  passing  the  data 
between  nodes  (  ref  para  3. 3. 3.1  ). 

3. 3. 4. 5  Sequencing  and  Segmentation  -  Sequencing  is 
normally  required  at  this  level  in  case  a  large  message  must 
be  fragmented  into  smaller  chunks  to  transit  the  network 
boundaries. 

At  the  Transport  level,  the  data  entity  is  the  Message. 
The  Message  size  is  variable  so  that  bandwidth  is  not 
wasted.  This  requires  a  field  in  the  Message  Header  to 
specify  the  Message  size.  The  maximum  Message  size  is  a 
function  of  the  maximum  VAX  data  transfer  rate.  If  this 
number  is  large  (i.e.  -  25  terminal  lines  X  80  chars/line  = 
2000  chars),  then  the  message  may  have  to  be  Segmented  with 
Transport  Header  Sequencing  information  to  identify  the 
parts  (packets)  of  the  Message  while  it  is  moving  about 


within  the  network.  The  receiving  end  collects  all  the 
message  parts  (packets)  and  reconstructs  the  original 


message  in  its  proper  order. 

This  feature  is  only  needed  for  large  file  transfers. 
The  only  large  file  transfer  within  the  FEP  system  consists 
of  the  host  sending  the  terminal  a  large  display  file. 
Therefore,  Message  Segmentation  would  normally  only  be 
required  at  the  VAX  node  (VPM)  while  Message  Reconstruction 
would  normally  only  be  required  at  the  LSI  (LTM)  end. 

However,  even  this  limited  application  of  segmentation 
is  not  really  required.  Since  there  can  be,  at  most,  one 
single  outstanding  frame  at  any  given  time  (  ref  para 
3. 3. 2. 2  ),  there  is  no  possibility  that  frames  will  be 
received  out  of  order.  Also,  there  is  no  special  action 
that  the  LSI  FEP  software  must  perform  upon  receipt  of 
process-to-screen  display  traffic.  It  is  transparent  to  the 
LSI  FEP  software  whether  the  characters  forwarded  to  the 
terminal  arrived  as  part  of  several  independent  messages  or 
as  segmented  frames  of  one  large  message.  Therefore, 
segmentation  and  reconstruction  would  introduce  unrequired 
complexity  into  the  system. 


However,  Transport  Header  sequencing  (  ref  Fig  3-4  ), 
mainly  used  at  this  level  for  segmentation,  will  be  retained 
as  part  of  the  "Support  for  LCN  Study"  (  ref  para  2. 2. 2. 3  ) 


requirement.  This  Message  Sequence  Number  will  be  used  to 
track  the  movement  of  the  message  through  the  network  nodes 
and  queues. 


3. 3 .4. 6  Command  Completion  Sensing  PAD  -  One  of  the  LSI 
(LTM)  responsibilities  is  to  assemble  a  complete  interactive 
request  and  ship  it  to  the  VAX.  Command  Completion  Sensing 
is  the  software  recognition  that  an  input  line  (assembled 
from  the  terminal)  is  complete  and  ready  for  VAX  processing. 
Normally,  a  carriage  return  signifies  the  point  at  which  the 
request  is  complete  (LINE  mode).  However,  certain  processes 
expect  and  respond  to  individual  keystroke  commands 
(CHARACTER  or  WORD  mode)  [7:3.43.  For  those  processes,  the 
LTM  node  must  be  "clued-in”  that  the  process  responds  to 
single  character  input.  Therefore,  a  Mode  field  is  included 
in  the  Transport  Header  (  ref  Fig  3-4  )  where-by  the  VPM 
node  will  inform  the  LTM  node  of  the  current  "mode"  of 
operation. 

3.3.5  Session  (LaY.er.53  - 

At  this  level,  a  Network  Status  and  Control  function 
exists  to  allow  the  System  Manager  to  initialize,  display 
status,  and  terminate  the  network.  System  level  alerts  and 
warnings  are  generated  and  sent  to  the  respective  system 
consoles  (LSI  SOC  or  VAX  SOC). 


Functions  at  this  level  typically  provide  the  user  with 
certain  useful,  but  not  always  essential,  services.  Among 


these  services  are  cryptographic  transformations,  text 
compression,  terminal  handling,  and  file  transfer  [5:386], 
These  functions  are  either  a)  not  required  for  the  FEP 
system,  or  b)  addressed  at  a  lower  protocol  level. 
Therefore,  no  Presentation  issues  were  designed  in  this 
investigation. 

3.3.7  Application  (Laver  71  - 

The  only  Application  function  identified  within  the 
system  is  the  Accounting  (and  disk  recording)  of  the 
queueing  statistics. 


3.4  Summary  - 


This  chapter  described  the  FEP  system  from  a  network 
perspective.  Logical  and  physical  nodes  were  defined  and 
identified.  The  ISO  protocol  model  was  used  to  explain  the 
services  and  requirements  at  each  level  of  the  network 
hierarchy.  Techniques  for  data  movement  and  control  within 
the  network  were  discussed.  Certain  traditional  protocol 


CHAPTER  4 


SOFTWARE  DESIGN  AND  IMPLEMENTATION 


This  chapter  describes  the  structural  design  and 
implementation  details  of  the  FEP  software  which  was 
expected  to  execute  on  the  LSI-11/23.  It  begins  with  a 
discussion  of  the  Software  Capabilities  and  Limitations 
which  influenced  and  bounded  the  implementation  effort. 
Next,  the  Software  Conventions  used  within  the  program  are 
discussed.  Then,  an  Overview  of  the  Software  Structure 
provides  a  skeletal  outline  of  the  program  processes. 
Finally,  the  Synopsis  of  Program  Modules  describes  the 
processing  steps  within  each  major  software  module. 

Supplementary  material  can  be  found  in  Appendix  B  (LSI 
FEP  Structure  Charts),  Appendix  C  (LSI  FEP  Data  Dictionary), 
Appendix  D  (LSI  FEP  Source  Code  Listings),  Appendix  E  (LSI 
FEP  Memory  Load  Map),  Appendix  F  (LSI  FEP  User's  Guide),  and 
Appendix  G  (LSI  FEP  Programmer's  Guide). 


4.1  Software  Capabilities  And  Limitations  - 


The  * C‘  language  was  selected  for  LSI  FEP 
implementation  because  of  its  availability  and  power  of 
expression  beyond  PASCAL.  The  version  of  *C*  run  on  the 
LSI-11/23  [21;  231  implemented  most  of  the  language 
Capabilities  [22] .  Those  capabilities  and  limitations  which 
are  of  particular  importance  to  this  thesis  effort  are 
discussed  in  the  following  paragraphs. 

4.1.1  Structured  Constructs  - 

'C  provides  the  fundamental  flow-control  constructions 
required  for  well-structured  programs:  decision  making  (  IF 
-  ELSE  );  looping  with  termination  at  the  top  (  WHILE, 
FOR  )  or  at  the  bottom  (  DO  ) ;  and  selecting  one  of  a  set 
of  possible  cases  (  SWITCH  )  [22:3].  Although 
non-structured  GOTO  and  LABEL  constructs  are  provided  within 
the  'C*  language,  neither  was  used  within  this  thesis 
implementation  in  order  to  preserve  the  top-down  execution 
flow. 


4.1.2  Data  Structure 
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The  fundamental  *  C *  data  structures  are  characters, 
integers,  and  floating  point  numbers.  In  addition,  there  is 
a  hierarchy  of  derived  data  types  created  with  pointers, 
arrays,  structures,  unions,  and  functions.  ’C'  provides 
pointers  and  the  ability  to  do  address  arithmetic.  The 
arguments  to  functions  are  passed  by  copying  the  value  of 
the  argument.  Therefore,  it  is  impossible  for  the  called 
function  to  change  the  actual  argument  in  the  caller.  When 
it  is  desirable  to  achieve  "call  by  reference”,  a  pointer 
may  be  passed  explicitly,  and  the  function  may  change  the 
object  to  which  the  pointer  points  [22:3]. 

4.1.3  Global  vg.-Jtetomallg-. /ariafrlss.  - 

Any  function  may  be  called  recursively,  and  its  local 
variables  are  "automatic"  or  created  anew  with  each 
invocation.  When  the  function  terminates,  its  automatic 
variables  are  destroyed.  Other  than  locally  defined  within 
the  function,  its  variables  may  be  external  (but  known  only 
within  a  single  source  file)  or  completely  global.  Both  of 
the  latter  types  remain  defined  throughout  program  execution 
and  can  be  referenced  by  all  program  functions  [22:31. 


4.1.4  Variable  Name  Lengths  - 


A  program  written  in  fCf  must  be  compiled  by  the  ' C ' 
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compiler  -  producing  a  macro  file  which  must  then  be 

assembled  using  the  RT-11  Macro  Assembler.  Therefore,  the 
* C '  source  program  must  comply  with  the  syntax  rules  of  both 
languages  in  order  to  produce  errorless  object  code.  The 
next  paragraph  indicates  a  few  areas  where  conflicts  exist 
between  the  syntax  rules  of  the  compiler  and  those  of  the 
assembler. 

\ 

Names  are  made  up  of  letters  and  digits;  the  first 
character  must  be  a  letter  in  ’C*  [22:333,  but  may  be  a 
number  for  the  RT-11  Macro  Assembler  [15:3-63.  The 
underscore  counts  as  a  letter  in  'C*  [22:333,  but  is 
rejected  as  an  invalid  character  by  the  RT-11  Macro 
Assembler  [15:3-63.  Only  the  first  8  characters  of  an 
internal  name  are  significant  in  ’C’,  although  more  may  be 
used  [22:333.  However,  the  RT-11  Macro  Assembler  only 
recognizes  the  first  6  characters  as  unique  and  significant 
[15:3-63. 

These  inconsistencies  forced  a  more  cryptic  naming  of 
certain  functions  and  variables  than  would  have  been 
desired. 


4.1.5  Limited  Symbolic  Definition  Capability  - 


Although  the  vendor  documentation  [21]  does  not 
reference  it,  an  upper  bound  does  exist  for  the  number  of 
user  defined  symbolic  constants  that  Telecon  ' C  *  will 


support  for  each  program  [23:6].  These  globally  defined 
constants  are  desirable  from  a  software  engineering  aspect 
due  to  the  resulting  ease  of  software  maintenance.  Although 
the  exact  threshold  was  never  calculated,  "LSIFEP.C" 
exceeded  it  several  times  during  the  development  effort. 
Each  such  instance  was  resolved  by  eliminating  some 
desirable  symbolic  constant  and  replacing  it  with  its 
hard-coded  value  wherever  it  was  referenced. 


4.2  Module  Communication  Conventions  - 

Very  few  conventions  were  designed  into  the  program  in 
order  to  simplify  its  maintenance.  A  small  set  of  global 
variables  were  declared  in  order  to  minimize  the  intermodule 
data-flow  complexity.  Most  intermodule  communication  takes 
place  via  character  arrays,  structure  tables,  and  indexes 
into  both. 

4*2.1  Character  Arrays  - 

Three  character  arrays  exist.  "InChar"  is  an  1800 
element  array  divided  into  9  parts  (  8  terminals  ports  +  1 
DMA  port  ),  each  containing  storage  for  200  characters. 
This  array  accepts  characters  via  interrupt  service  routine 
processing  of  terminal  keyboard  input  characters.  "OutChar" 


is  an  identically  configured  array  which  contains  output 


characters  destined  for  output  to  one  of  the  8  terminal 
display  screens.  "NodeChar”  is  a  4000  element  array  divided 
into  2  parts  (  terminal-to-DMA  and  DMA-to-terminal  traffic  ) 
containing  storage  for  2000  characters  each.  This  array 
serves  as  a  queueing  buffer  for  complete  message  transfers 
between  network  nodes. 

4.2.2  Structure  Tables  - 

Three  structure  tables  exist.  The  Port  Status  Table 
(  "PST"  )  contains  buffer  indexes,  I/O  port  addresses,  and 
other  information  desribing  the  status  of  each  of  9  ports. 
The  Node  Buffer  Table  (  "NBT"  )  contains  buffer  indexes  and 
the  node  identification  information  required  for  moving 
message  traffic  between  the  two  LSI  FEP  nodes.  The 
Transport  Header  Table  (  nTHTn  )  contains  the  Message 
Transport  Header  skeleton  which  is  prefixed  to  each  message 
prior  to  movement  of  that  message  to  one  of  the  node  queues. 

4.3  Overview  Of  The  Software  Structure  - 

Utilizing  the  RT11XM  extended  memory  features,  the 
LSIFEX.SAV  executable  image  was  created  by  specifying  to  the 
RT-11  Linker  the  order  and  relative  locations  desired  for 
the  seven  object  modules  which  form  the  LSI  FEP  software. 
Likewise,  the  low  memory  features  of  the  RT11SJ  monitor  were 


used  to  create  the  "LSIFEP . SAV"  program  image. 

The  source  code  programs  which  generate  these  seven 
modules  are  classified  according  to  placement  within  memory 
and  are  discussed  in  the  following  sections.  Program  names 
ending  with  n.C”  are  ’C*  source  programs  while  those  ending 
with  ".MAC"  are  macro  assembly  language  programs.  A  Load 
Map  of  "LSIFEX.SAV"  is  contained  in  Appendix  E.  Figure  4-1 
contains  a  graphic  representation  of  central  memory 
placement  of  the  software  modules  within  "LSIFEX.SAV". 


4.3.1  Low  Memory  Software  - 

Software  placed  within  the  confines  of  low  memory 
included  those  functions  and  data  areas  which  were 
constrained  (  ref  para  2.3.7  )  to  reside  there  and  those 
data  areas  (  primarily  NBUFF.MAC  )  which  served  as  filler  to 
ensure  that  the  PARI  restrictions  (  ref  para  2.3.7  )  were 
met. 


4. 3. 1.1  LFEPIO.C  -  The  LSI  FEP  Input/Output  ' C *  module  is 
a  derivation  of  the  Standard  I/O  package  (STDIO.H)  included 
with  the  fC’  compiler  [22:143  and  21:8],  Routines 
non-essential  to  the  LSI  FEP  software  and/or  not  supported 
by  the  Telecon  ’C*  compiler  were  removed  in  order  to  save 
memory. 
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Fig.  4-1  LSIFEX  Memory  Layout 


4. 3. 1.2  LFMLLO.MAC  -  The  LSI  FEP  Macro  Library  (  Low 
Memory  )  assembly  module  is  a  derivation  of  the  Telecon  'C' 
Runtime  Support  Library  "CLIB1 1 .MAC"  [21]  as  augmented  by 
previous  classroom  (  EE6.90  -  Real  Time  Programming 
Laboratory  )  upgrades.  Again,  non-essential  functions  were 
removed.  The  remaining  program  was  further  divided  into  a 
portion  (LFMLLO.MAC)  that  was  constrained  (  ref  para  2.3.7  ) 
to  reside  in  low  memory  and  a  portion  (LFMLHI.MAC)  that 
could  reside  in  extended  memory. 

4. 3. 1.3  NBUFF.MAC  -  The  Node  Buffer  macro  program  contains 
the  data  item  definitions  which  define  the  size  and  start 
address  of  the  character  array  "NodeChar" . 

4. 3. 1.4  LFEPLO.C  -  The  LSI  FEP  (  Low  Memory  )  »C»  program 
contains  the  main  functions  which  implement  the  LSI  FEP 
processing.  Program  initialization,  interrupt  servicing, 
background  processing,  and  program  termination  are  contained 
there. 

4. 3. 1.5  TBUFF.MAC  -  The  Terminal  Buffer  macro  program 
contains  the  data  item  definitions  which  define  the  sizes 
and  starting  addresses  of  the  terminal  character  arrays 
"InChar"  and  "OutChar". 

4.3.2  Extended  Memory.  Software  - 

Two  software  programs  were  placed  into  the  extended 


memory  portion  of  the  LSI-11/23  physical  address  space. 
These  programs  contained  no  functions  which  were  called  by 
interrupt  processing  routines.  Therefore,  the  PARI 
restriction  (  ref  par  2.3.7  )  did  not  apply  to  them. 

4 .3 .2.1  LFEPHI .C  -  The  LSI  FEP  (  High  Memory  )  1 C*  program 
contains  routines  called  during  synchronous  processing 
events.  Typically,  these  routines  provide  some  low  priority 
processing  such  as  displaying  some  aspect  of  the  system 
status  upon  the  SOC  terminal  screen  or  recording  the 
accounting  statistics. 

4. 3. 2. 2  LFMLHI.MAC  -  The  LSI  FEP  Macro  Library  (  High 
Memory  )  assembly  module  contains  those  functions  (  ref  para 

4. 3. 1.2  )  which  could  be  removed  to  extended  memory. 
Typically,  these  functions  provided  communication  with  the 
floppy  disk  files. 


4.4  Synopsis  Of  Program  Modules  - 

Program  modules  reside  either  in  low  memory  or  in 
extended  memory. 

4.4.1  Low  Memory  Modules  - 

The  following  modules  perform  the  main  functions  of  the 


LSI  FEP  software 


4. 4. 1.1  Main  -  This  module  (module  0)  is  the  top  segment 
to  which  control  is  transferred  by  the  *C'  Shell  upon 
program  initiation.  This  module  calls  "InitSystem"  to 
initialize  the  database  and  activate  interrupts.  It  then 
calls  "Perf NormalActivities"  to  perform  the  synchronous 
tasks  (  move  data  between  nodes,  output  characters  to  the 
terminal  screens,  etc.  ).  When  the  SOC  operator  aborts  the 
system  (  ref.  paras  4. 4. 1.5  and  4.4.1.15  ),  then  control  is 
returned  to  this  module  which  then  calls  "TermSystem"  to 
deactivate  interrupts  and  close  files.  The  module  finishes 
its  processing  by  an  exit  to  the  RT11XM  monitor. 

4. 4. 1.2  InitSvstem  -  This  module  (module  1)  controls  the 
database  initialization.  It  begins  processing  by  opening 
the  LSIFEP.DAT  accounting  file.  It  then  sets  up  the  four 
pointers  (  ref  para  3. 3. 3. 3  )  into  the  terminal  buffers 
"InChar"  and  "OutChar"  for  each  of  the  nine  entries  in  the 
Port  Status  Table  (PST).  It  then  sets  up  the  four  pointers 
into  the  "NodeChar”  buffer  for  each  of  the  two  entries  in 
the  Node  Buffer  Table  (NBT).  It  then  moves  the  address  of 
each  interrupt  service  routine  into  the  corresponding  entry 
of  the  PST  for  easy  retrieval  by  the  nlnitlnterrupts" 
routine.  It  then  calls  "InitPST"  to  complete  the  PST 
initialization.  It  then  calls  "Initlnterrupts”  for  each 
entry  in  the  PST  to  initialize  the  interrupt  for  that  port. 


4.4.1 .3  InitPST  -  This  module  (module  1.1)  begins 
processing  by  coding  each  PST  entry  with  a  unique  terminal 
identification  (TID).  It  then  fetches  and  moves  to  the  PST 
the  addresses  of  the  four  port  I/O  interface  registers: 
Receiver  Control  and  Status  Register  (RCSR),  Receiver  Buffer 
Register  (RBUF),  Transmitter  Control  and  Status  Register 
(XCSR),  and  Transmitter  Buffer  Register  (XBUF)  [20:221-223] 
for  each  of  the  nine  entries  in  the  PST.  It  also  moves  the 
address  of  each  interrupt  vector  [20:508-509]  to  the  nine 
entries  of  the  PST.  It  completes  processing  by  initializing 
the  terminal  mode  (  ref  para  3. 3. 4. 6  )  to  "LINE"  mode. 

4. 4. 1.4  Initlnterrupts  -  This  module  (module  1.2) 
activates  the  interrupts  for  each  of  the  nine  ports  defined 
in  the  PST.  It  begins  processing  by  setting  up  a  Processor 
Status  Word  (PSW)  mask  [20:176-177;  207-209].  It  then  saves 
(in  the  PST)  the  current  contents  of  the  port's  interrupt 
vector  and  interrupt  PSW.  It  then  resets  these  two 
locations  to  the  address  of  the  interrupt  service  routine 
(fetched  in  "InitSystem”)  and  the  new  PSW  mask  just 
generated.  It  then  turns  on  the  Interrupt  Enable  bit  (bit 
6)  of  the  corresponding  RCSR  [20:221], 

4. 4. 1.5  SOCInterruptServ ice Routine  -  This  module  (module 
1.2.1)  executes  when  control  is  passed  to  it  by  the  RT11XM 
monitor  in  response  to  a  console  keyboard  action  at  the 
System  Operator  Console  (SOC).  It  begins  processing  by 


calling  "entint"  to  save  the  register  values  of  the 
interrupted  program.  It  then  copies  the  input  character  to 
the  input  queue  "InChar"  and  echoes  the  character  to  the 
console  screen.  If  the  character  was  a  carriage  return,  the 
module  echoes  a  line  feed  character  to  the  screen.  If  it 
was  a  Control-C  (*C),  special  termination  processing  occurs. 
If  it  was  a  "delete"  character,  special  processing  occurs. 
If  it  was  neither,  the  InChar  "put"  index  is  incremented  for 
the  next  character. 


The  AC  input  signals  the  SOC  operator’s  intention  to 
abort  the  LSI  FEP  system.  This  input  results  in  the  module 
setting  the  "AbortFlag"  boolean  variable  to  "YES".  This 
flag  is  checked  in  module  "Perf NormalActivities" . 


A  "delete"  character  requires  special  treatment 
because,  instead  of  adding  characters  to  "InChar",  this 
action  results  in  withdrawing  characters.  Processing 
consists  of  verifying  that  the  "delete"  character  was  not 
the  first  character  typed.  This  ensures  that  at  least  one 
character  already  exists  in  the  buffer  and  can  be  deleted. 
If  such  a  character  exists,  then  the  "InChar"  "put"  index  is 
decremented  so  that  the  next  input  character  will  over-write 
the  character  intended  for  deletion.  Then,  to  clean-up  the 
display  terminal,  a  series  of  "backspace"  and  "space" 
characters  are  output  to  blank  out  the  deleted  character  and 


reposition  the  screen  cursor. 


Processing  terminates  during  a  call  to  "retint"  which 
restores  the  register  contents  of  the  interrupted  program 
and  executes  the  "RTI"  (  return  from  interrupt  )  assembly 
language  instruction. 

4.4.1  .6  T1 InterruptServiceBoutine  -  This  module's  (module 

1.2.2)  processing  is  identical  to  that  of  module  1.2.1 

except  that  it  performs  no  special  processing  for  the  ~C 
input  and  it  services  character  input  from  terminal  1 . 

4.4.1 .7  T2 Interrupt Service Routine  -  This  module's  (module 

1.2.3)  processing  is  identical  to  that  of  module  1.2.2 

except  that  it  services  characters  input  from  terminal  2. 

4. 4. 1.8  T3 Interrupt Service Routine  -  This  module's  (module 

1.2.4)  processing  is  identical  to  that  of  module  1.2.2 

except  that  it  services  characters  input  from  terminal  3. 

4. 4. 1.9  T4Interrupt Service Routine  -  This  module's  module 

1.2.5)  processing  is  identical  to  that  of  module  1.2.2 

except  that  it  services  characters  input  from  terminal  4. 

4.4.1.10  T5InterruPtServioeRoutine  -  This  module's  (module 

1.2.6)  processing  is  identical  to  that  of  module  1.2.2 

except  that  it  services  characters  input  from  terminal  5. 

4.4.1.11  T6lnterruptServlceRoutlne  -  This  module's  (module 


1.2.7)  processing  is  identical  to  that  of  module  1.2.2 
except  that  it  services  characters  input  from  terminal  6. 


4.4.1  .12 


-  This  module's  (module 


1.2.8)  processing  is  identical  to  that  of  module  1.2.2 
except  that  it  services  characters  input  from  terminal  7. 


4.4.1  .13 


-  This  module  (module 


1.2.9)  services  all  DMA  interrupts.  It  begins  processing  by 
determining  the  reason  for  the  interrupt.  If  non-existant 
memory  was  accessed,  it  sends  an  error  alert  to  the  SOC.  If 
the  host  has  raised  an  input  request,  this  module  calls 
"SetUpForlnputDMA"  to  process  the  request.  If  none  of  the 
above  reasons,  it  bases  further  processing  upon  the  last 
reported  status  of  the  "DMABusyFlag". 

If  a  word  mode  input  was  expected,  the  word  is  fetched 
and  inspected.  This  word  represents  the  host's  word  count 
for  an  ensuing  block  mode  transfer  of  data  across  the  DMA 
channel.  If  sufficient  buffer  space  exists  in  "NodeChar"  to 
hold  a  message  of  this  many  characters  (twice  the  word 
count),  the  DMA  interface  is  programmed  [I8:chapter  4]  to 
expect  a  block  mode  DMA  input  from  the  host.  If  buffer 
space  does  not  exist,  an  error  alert  is  issued  to  the  SOC 
screen. 


If  a  block  mode  input  was  expected,  then  this  interrupt 
notifies  the  LSI  that  the  block  transfer  has  completed.  The 
module  adjusts  the  NBT  pointers  into  "NodeChar"  and  resets 
the  "DMABusyFlag"  to  input  word  expected. 


If  a  word  mode  output  was  in  progress,  then  this 
interrupt  signals  the  host  response  to  the  block  mode  output 
request.  If  the  host  is  prepared  to  accept  the  data  block, 
the  DMA  interface  is  programmed  for  block  mode  output  and 
the  "DMABusyFlag"  is  set  to  block  mode  output  in  progress. 

If  a  block  mode  output  was  in  progress,  then  this 
interrupt  signals  the  completion  of  the  output  transfer. 
The  "DMABusyFlag”  is  reset  to  word  mode  input  expected  and 
the  DMA  interface  is  programmed  accordingly. 

4.4.1.14  SeJbUoForlnputDMA  -  This  module  (  module  1.2. 9.1  ) 
begins  processing  by  setting  the  "DMABusyFlag"  to  word  mode 
input  expected.  It  then  programs  the  DMA  interface 
accordingly. 


4.4.1  .15 


-  This  module  (  module  2  ) 


begins  its  processing  by  displaying  upon  the  SOC  terminal 
the  time  at  which  the  LSI  FEP  system  was  activated.  It  then 
enters  the  large  system  idle-loop  (  ref.  section  2.3.2  ) 
which  encompasses  all  synchronous  processing  tasks.  The 
software  will  continue  to  idle  within  this  loop  as  long  as 
the  data  item  "AbortFlag"  remains  equal  to  the  boolean 
constant  "NO"  (  defined  as  0  ) .  When  the  SOC  operator  keys 
in  a  control-C  ('"C),  then  "AbortFlag"  is  set  to  the  boolean 
"YES"  (  defined  as  1  ) .  When  the  bottom  of  the  loop  is 
reached,  the  status  of  "AbortFlag"  is  checked.  If  it  equals 
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"YES",  then  the  statement  following  the  loop  (  return  to 
"Main"  )  is  executed. 

Within  the  loop,  three  main  synchronous  tasks  are  done. 
For  each  terminal,  if  new  characters  have  been  deposited  in 
the  terminal  input  buffer  by  the  interrupt  service  routines, 
then  "SrvInputQueue”  is  called  to  service  that  input  queue. 
Likewise,  if  output  characters  have  been  deposited  in  one  of 
the  output  queues,  then  "SrvOutputQueue"  is  called  to 
service  that  output  queue.  If  a  message  exists  in  one  of 
the  node  queues,  then  "SrvNodeQueue"  is  called  to  service 
that  message. 

If  no  work  exists  when  a  particular  queue  is  checked, 
then  the  "put"  and  "get"  pointers  are  reset  to  their  "low" 
value.  This  step  is  required  because  a  previous  design 
decision  (  ref  para  3. 3. 3. 3  )  disallowed  circular  buffering. 
By  synchronously  resetting  empty  buffer  pointers  to  their 
initialized  values  (  ref  para  4.4.2  ),  the  software  ensures 
that  the  full  buffer  capacity  is  available  for  the  next  data 
entry. 

4.4.1.16  SrvInnutQueue  -  This  module  (  module  2.1  )  scans 
the  input  character  buffer  "InChar".  If  the  character 
currently  being  scanned  is  a  carriage  return  or  if  the 
terminal  is  in  the  "CHARACTER"  mode,  then  a  complete  user 
request  is  present  and  can  be  assembled  for  DMA  transfer  to 


the  host. 


Otherwise,  the  next  character  in  the  buffer  is 
scanned  and  similar  testing  performed  until  all  the 
characters  in  the  buffer  have  been  scanned. 

If  a  complete  request  exists  in  "InChar",  then  a  check 
is  made  as  to  whether  the  SOC  buffer  is  being  scanned.  If 
yes,  then  module  wEvalSOCInputH  is  called  to  determine  if 
DMA  transfer  is  required.  After  this  test,  and  if  DMA 
transfer  is  required,  then  a  character  count  is  calculated 
for  inclusion  in  the  Transport  Header  (  ref  para  3. 3. 4. 5  ). 
Since  the  DMA  interface  requires  full  word  (two  character 
bytes)  transfers  [18:4.93,  an  odd  number  value  for  the 
message  size  is  incremented  to  make  it  even. 

If  buffer  space  exists  to  hold  a  message  of  this 
character  count,  module  "MoveMsgtoNodeTTxDMA"  is  called. 
Otherwise,  an  error  alert  is  issued  to  the  SOC  screen. 

4*4*1-17  Ev.3lSQCXnPVt  -  This  module  (  module  2.1.1  ) 
determines  if  a  SOC  system  status  request  has  been  issued. 
If  so,  then  this  request  will  be  processed  locally  within 
the  LSI  and  not  forwarded  to  the  host.  If  not,  then  the 
"goDMAFlag”  is  set  to  nYESn  for  nSrvInputQueuew  processing. 

If  the  SOC  request  is  to  display  the  PST,  then 
"DispPST"  is  called.  If  the  SOC  request  is  to  display  the 
NBT,  then  "DispNBT"  is  called.  If  the  SOC  request  is  to 
display  the  current  system  time,  then  "DispTime"  is  called. 
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4.4.1  .18 


This 


module 


(  module 


2.1.2  )  is  called  by  "SrvInputQueue"  when  a  DMA  output 
transfer  is  required.  This  module  calls  module 
"BldTransportHeader"  to  construct  the  Transport  Header  (  ref 
Fig  3-4  ).  It  then  moves  the  Transport  Header  characters 
into  "NodeChar"  followed  by  the  "InChar"  terminal  request 
characters.  If  the  number  of  characters  in  the  terminal 
message  is  odd,  then  a  harmless  line-feed  character  is  added 
to  "NodeChar"  to  pad  the  message  into  an  even  word  block. 
Module  "GatherStats"  is  then  called  to  record  the  accounting 
data  of  this  message's  entry  into  a  queue. 

4.4.1.19  BldTransportHeader  -  This  module  (  module 
2. 1.2.1  )  constructs  the  Transport  Header  as  defined  in 
Figure  3-4.  Processing  consists  of  the  movement  to  the 
Transport  Header  Table  (THT)  skeleton  of  either  single 
character  bytes  or  strings  of  bytes  (via  calls  to  the 
"strcopy"  module).  Also,  integer  to  ASCII  character 
conversion  of  numeric  quantities  is  accomplished  by  call  to 
subroutine  "intascii". 

4.4.1.20  SrvOutPutQueue  -  This  module  (  module  2.2  )  moves 
character  data  from  "OutChar"  to  the  Transmitter  Buffer 
Register  (XBUF)  for  display  upon  the  user  terminal  screen. 
If  the  Transmitter  Control  and  Status  Register  (XCSR) 
transmit  ready  bit  (bit  7)  is  set  r  1 ,  then  a  new  character 
can  be  moved  to  the  XBUF.  Otherwise,  this  module  returns  to 


”Perf NormalActi vities"  to  continue  other  processing. 

4. 4. 1.21  SrvNodeQueue  -  This  module  (  module  2.3  ) 
controls  the  movement  of  messages  between  LSI  FEP  network 
nodes.  Two  nodes  exist.  The  first  node  (entry  0  in  NBT)  is 
labeled  TTxDMA  and  is  used  to  hold  message  traffic  input 
from  the  terminal  which  is  intended  for  output  along  the  DMA 
interface.  The  other  node  (entry  1  in  NBT)  is  labeled 
DMATTx  and  is  used  to  hold  the  DMA  input  message  traffic 
which  is  destined  for  output  to  the  terminal  screen. 

Processing  begins  by  scanning  the  Transport  Header 
(  fig  3-4  )  to  determine  message  length  and  terminal 
identifier  (TID).  Subroutine  "strcompare"  is  called  to 
compare  the  message  TID  with  those  recognized  by  the  system 
and  stored  as  entries  in  the  PST.  If  no  match  is  found,  an 
error  alert  is  issued  to  the  SOC  terminal  screen  and  the 
node  is  flushed  of  all  message  data  by  re-initializing  the 
"NodeChar"  indexes. 

If  a  match  is  found,  then  the  ASCII  message  character 
count  is  fetched  from  the  Transport  Header  and  converted  to 
integer  via  a  call  to  "asciiint" .  If  the  node  being  scanned 
is  TTxDMA,  then  module  "TTxtoDMAOutput"  is  called. 
Otherwise,  "DMAtoTTxOutput"  is  called. 


4.4.1.22  TTxtoDMAOutPut  -  This  module  (  module  2.3.1  ) 
activates  the  DMA  output  request  to  the  host  computer.  If 
the  "DMABusyFlag"  status  indicates  word  mode  input  expected 
and  the  DMA  Control  and  Status  Register  (DMACSR)  reports  the 
DMA  idle,  then  the  DMA  interface  is  programmed  for  word  mode 
output  and  the  "DMABusyFlag"  is  set  to  word  mode  output  in 
progress.  The  word  that  is  output  is  the  character  count  of 
the  message  which  would  be  sent  to  the  host  in  block  mode. 
Subroutine  "GatherStats"  is  called  to  record  the  release  of 
message  data  from  the  TTxDMA  queue. 

If  either  condition  is  not  met,  an  error  alert  is 
issued  to  the  SOC  terminal  screen. 

4.4.1.23  DMAtoTTxOutPut  -  This  module  (  module  2.3.2  ) 
controls  the  movement  of  message  data  (received  from  the  DMA 
interface)  from  the  DMATTx  buffer  to  the  appropriate 
"OutChar"  buffer.  First,  "GatherStats"  is  called  to  record 
the  release  of  message  data  from  the  DMATTx  queue.  Next, 
the  Terminal  Mode  field  in  the  Transport  Header  (  Fig  3-4  ) 
is  moved  to  the  corresponding  PST  entry.  Finally,  each 
message  character  is  copied  from  the  "NodeChar"  buffer  to 
the  appropriate  "OutChar"  buffer  and  pointers  adjusted 
accordingly. 

4.4.1.24  TermSvstem  -  This  module  (  module  3  )  is  executed 
once  after  "AbortFlag"  has  been  set  to  "YES"  in 


"SOCInterruptServ iceRout ine"  and,  in  response,  the  large 
loop  in  "Perf NormalActi vities"  terminates  and  returns 
control  to  the  top  segment  "Main". 

"TermSystera"  restores  all  interrupt  vectors  and 
Processor  Status  Words  (PSW)  (  ref  para  4. 4. 1.4  )  to  their 
original  contents.  A  message  is  then  output  to  the  SOC 
terminal  indicating  the  time  at  which  the  "abort"  command 
was  processed  and  the  duration  of  the  LSI  FEP  processing. 

File  "LSIFEP.DAT"  is  then  closed  and  the  software  exits 
to  the  RT-11  monitor. 

4.JJ.2  Extended  Memory  Modules  - 

The  following  paragraphs  describe  the  '  Cf  modules  which 
have  been  mapped  to  extended  memory.  These  modules 
typically  provide  services  to  the  synchronous  processing 
modules  described  earlier  (  ref  para  4.4.1  ).  Since  these 
services  possess  no  hierarchical  relationships  to  each 
other,  the  module  ordering  conventions  were  arbitrarily 
assigned  as  the  need  for  a  new  service  became  known.  The 
module  numbers  represent  the  order  in  which  the  modules 
appear  in  the  program  section  'LFEPHI.C'.  To  preclude 
confusing  these  module  numbers  with  those  of  ’ LFEPLO.C’, 
each  extended  memory  module  number  will  contain  an  ’X' 


prefix. 


4. 4. 2.1  DispPST  -  This  module  (  module  X.1  )  displays  the 
status  of  selected  fields  of  the  Port  Status  Table  (PST) 
upon  the  SOC  terminal  screen.  The  format  of  this  display  is 
contained  in  Figure  F-4  of  Appendix  F. 

4. 4. 2. 2  DispNBT  -  This  module  (  module  X.2  )  displays  the 
status  of  selected  fields  of  the  Node  Buffer  Table  (NBT) 
upon  the  SOC  terminal  screen.  The  format  of  this  display  is 
contained  in  Figure  F-3  of  Appendix  F. 


4. 4. 2. 3 


-  This  module  (  module  X.3  )  calls 


an  assembly  language  routine,  'gtime’,  which  fetches  the 
current  system  time  and  returns  it  in  a  two  word  parameter 
table.  This  module  then  decodes  these  two  words,  converts 
the  numbers  to  ASCII  characters  and  produces  a  displayable 
time  in  the  format  of  HH:MM:SS:TT  where  HH  s  hours,  MM  = 
minutes,  SS  =  seconds,  TT  =  ticks  (60  ticks  per  second). 

Four  global  data  items  ('StartHr’,  ’StartMin1, 
•StartSeC,  ’StartTic')  are  defined  to  contain  the  initial 
start-up  time  of  the  LSI  FEP  system.  These  start-up  values 
are  subtracted  from  the  time  calculated  at  system 
termination  to  provide  the  elapsed  time  for  the  LSI  FEP 
operation.  These  data  items  are  initialized  with  the 
current  system  time  during  the  initial  calling  of 
’ GetCurrentTirae’ . 
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4. 4. 2. 4  DispTime  -  This  module  (  module  X.4  )  calls 
'GetCurrentTime'  (module  X.3)  and  then  displays  the 
formatted  time  upon  the  SOC  terminal  screen. 

4. 4. 2. 5  CalcElapsedTime  -  This  module  (  module  X.5  )  is 
called  once  -  at  LSI  FEP  system  termination.  This  module 
calls  ’GetCurrentTime'  (module  X.3)  to  fetch  the  current 
system  time.  It  then  subtracts  this  time  from  the  four 
start-up  values  and  provides  an  elapsed  time. 

4. 4. 2. 6  DispElapsedTime  -  This  module  (  module  X.6  )  calls 
'CalcElapsedTime'  (module  X.5)  to  calculate  the  elapsed 
time.  It  takes  the  elapsed  time  and  converts  the  integer 
values  to  ASCII  characters  and  displays  the  result  upon  the 
SOC  terminal  in  the  form  HH:MM:SS:TT. 

4.4 .2.7  GatherStats  -  This  module  (  module  X.7  )  records 
the  accounting  data  for  LCN  queueing  study  (  ref  para 
2. 2. 3. 3  ).  Calling  parameters  to  this  subroutine  are  a 
pointer  to  a  character  string  which  forms  a  Transport  Header 
(  ref  Fig  3-4  )  and  a  reason  code  specifying  which  action 
(  1  =  queue  entry,  2  =  queue  exit)  is  being  recorded. 
Processing  begins  with  a  call  to  'GetCurrentTime'  (module 
X.3)  to  fetch  the  current  time.  The  time,  action  code,  and 
Transport  header  are  then  written  to  the  disk  file 
'LSIFEP.DAT'  in  the  format  specified  in  Figure  F-5. 
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4.5  Summary  - 


This  chapter  described  the  software  design  and 
implementation  details.  It  began  by  discussing  the 
capabilities  and  limitations  of  the  Telecon  * C '  language. 
Next,  programmer  conventions  for  inter-module  software 
communication  were  outlined.  The  chapter  continued  with  an 
overview  of  the  software  structure  -  describing  the  programs 
which  reside  in  low  memory  and  those  which  reside  in 
extended  memory.  The  chapter  concluded  by  presenting  a 
synopsis  of  program  modules  which  reside  in  the  LSI  FEP  (Low 
Memory)  and  LSI  FEP  (High  Memory)  programs. 
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CHAPTER  5 

SOFTWARE  TEST  AND  EVALUATION 


This  chapter  describes  the  testing  phase  of  the 
Software  Development  Life  Cycle  (  ref  para  1.5. 1.5  ).  It 
begins  with  a  short  discussion  of  Testing  Methodology  and 
ends  with  a  presentation  of  the  Testing  Results. 


5.1  Testing  Methodology  - 


Two  testing  strategies  were  used  during  this 


investigation. 


coarse  test  was  conducted  using 


Requirements-based  testing  [31:1853.  A  more  detailed  test 
was  conducted  using  a  Program-based  testing  [31:1953 
approach. 


5.1 .1 


The  traditional  requirements-based  testing  method  is 
functional  testing.  In  functional  testing,  a  program  or 


software  system  is  viewed  as  a  "black  box"  which  accepts 
known  inputs,  applies  the  relevant  function  to  these  inputs, 
and  generates  outputs  [31:185].  It  is  usually  applied  over 
a  range  of  classes  of  input  data  and  typically  delivers 
output  belonging  to  one  of  a  number  of  different  possible 
classes. 

A  rigorous  functional  test  would  include  selecting  the 
input  data  classes,  identifying  extreme  cases  and  boundary 
conditions,  and  establishing  the  class  categories  for  the 
expected  output.  The  successful  accomplishment  of  these 
steps  pre-supposes  the  existence  of  concise  and  detailed 
requirements  and  specification  documents. 

Due  to  the  general  nature  of  the  FEP  Software 
Requirements  Analysis  (  ref  Chapter  2  and  Appendix  A  ),  such 
a  rigorous  functional  test  could  not  be  conducted.  The 
system  functional  requirements  were  presented  in  a 
descriptive  rathei^  than  quantitative  manner.  Furthermore, 
the  full  set  of  software  requirements  (  Appendix  A  )  was 
consolidated  into  a  summary  table  (  Table  1-1  )  for  easier 
assimilation.  This  summary  table  was  then  further  condensed 
into  the  page  length  System  Level  Requirements  Table  (  Table 
2-1  )  upon  which  the  requirements  prioritization  (  ref  para 
2.2  )  and  software  design  (  ref  Chapter  4  )  were  based. 

Therefore,  it  is  this  final  capsule- format  of  the 


functional  requirements  which  the  functional  test  would  be 
conducted  against.  Since  this  generalized  format  precluded 
an  in-depth  functional  test,  the  goals  of  the  functional 
test  were  altered. 

Rather  than  test  implemented  functions  at  a  microscopic 
level,  it  was  decided  that  the  test  should  be  conducted  at  a 
macroscopic  level.  'The  resulting  purpose  of  the  test  was  to 
identify  the  presence,  absence,  and  well-being  of  the 
functions  displayed  in  Table  2-1.  In  other  words,  rather 
than  providing  concise  quantitative  results,  the  test  would 
produce  a  high  level  survey  of  implementation  completeness. 
This  test  was  performed  mostly  by  inspection  and  it 
identified  functions  (  ref  Table  5-1  )  which  were: 

a.  implemented  with  no  obvious  high-level  limitations 

b.  implemented  with  observable  high-level  limitations 

c.  not  implemented  (due  to  prioritization  decisions) 

5.1.2  Program-fraged,. Testing  - 

One  of  the  weaknesses  of  requirements  testing  is  its 
failure  to  test  computational  features  of  a  program  which 
are  related  to  the  design  and  implementation  of  the  program 
and  which  are  not  a  part  of  its  requirements  [31s 1953. 
Program-based  t  sting  evolves  the  selection  of  test  data 
which  tests  recific  computational  structures  of  the 


program.  The  most  widely  studied  program-based  testing 
methods  are  those  that  involve  the  selection  of  test  data 
which  causes  the  execution  of  specific  statements,  branches, 
or  paths  of  the  program.  These  methods  are  referred  to  as 
"structured  testing  methods"  [31:1953. 

5.1  .2.1  Branch  Testing  -  Branch  testing  was  the  earliest 
form  of  structured  testing  to  be  studied  and  systematically 
applied  to  the  testing  of  programs  [31:1963.  The  technique 
requires  that  test  data  be  constructed  that  causes  each 
branch  in  a  program  to  be  transversed  at  least  once. 

5. 1.2. 2  Statement  Testing  -  A  more  restricted  kind  of 
structured  testing,  statement  testing,  requires  that  each 
statement  in  a  program  be  executed  at  least  once  on  some 
test  [31:1963. 

5. 1.2. 3  Path  Testing  -  Several  studies  of  the 
effectiveness  of  branch  testing  indicates  that  there  are 
large  numbers  of  errors  whose  existence  is  not  necessarily 
revealed  by  the  testing  of  all  branches  in  a  program 
[31:1993.  Many  of  these  errors  are  related  to  combinations 
of  branches  and  are  revealed  only  by  a  test  that  causes  a 
program  path  to  be  followed  which  contains  the  combination. 
Path  testing  requires  that  every  "logical  path"  through  a 
program  should  be  tested  at  least  once.  The  difficulty  with 
this  idea  is  that  a  program  which  contains  loops  will,  in 


general,  have  an  infinite  number  of  possible  paths  131:199]. 


5.2  Testing  Results  - 


Both  requireraents-based  (black  box)  and  program-based 
(white  box)  testing  were  performed.  As  discussed 
previously,  the  black  box  testing  was  conducted  as  a  survey 
approach  to  assessing  the  functional  completeness  of  the  LSI 
FEP  software  implementation. 


Branch  testing  was  chosen  as  the  program-based  testing 
strategy  because  it  enabled  a  thoroughness  beyond  that  of 
statement  testing,  yet  avoided  the  prohibitively  expensive 
effort  of  a  comprehensive  path  testing.  It  was  complemented 
throughout  the  software  development  process  by  informal  code 
walk-throughs  conducted  by  the  author. 


5.2.1 


Table  5-1  indicates  that  all  of  the  Top  priority,  High 
priority,  and  Medium  priority  (  ref  para  2.2  )  software 
requirements  have  been  implemented  to  some  extent.  The 
following  paragraphs  describe  those  requirements  in  Table 
5-1  which  failed  the  requirements-based  testing. 


5.2.1  .1 


-  Although  the  scope  of 


this  thesis  project  specifically  limited  the  implementation 
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effort  to  LSI  FEP  software  only  (  ref  para  1.4  ),  this 
requirement  was  deemed  an  initial  failure  because  the  system 
could  not  function  properly  without  VAX  FEP  software  being 
implemented  on  the  host. 

5. 2. 1.2  Comm  Link  Support  (Host  0/S)  -  Neither  DEC  nor 
Able  Computer  Technology,  Inc  provided  a  VAX/VMS  software 
device  driver  to  support  the  DR-1  IB  Direct  Memory  Access 
(DMA)  board.  This  deficiency  provided  the  single  critical 
limiting  factor  in  the  FEP  implementation  and  testing. 

C  Note:  A  possible  DR-11 B  driver  has  been  located 
at  GD  Serle  (Illinois)  and  efforts  are 
underway  to  procure  a  copy  of  this  driver.  ] 

Without  a  working  driver  on  the  host  end  of  the  comm 
link,  most  of  the  LSI  FEP  comm  link  software  could  not  be 
tested  (  ref  para  2.2.1  ).  The  purpose  of  a  network 
protocol  is  to  provide  mutually  agreed  upon  handshaking 
between  cooperating  computers.  This  goal  cannot  be  realized 
when  the  distant  end  (host)  is  not  capable  of  handshaking. 

Although  Transport  Layer  protocol  (  ref  para  3.3.4  ) 
was  implemented,  no  attempt  was  made  to  code  the  Data  Link 
Layer  protocol  (  ref  para  3.3.2  ).  It  was  not  clear  that 
the  latter  protocol  was  i eally  required  and  the  lack  of  a 
host  driver  provided  no  resolution  of  the  issue. 


5.2.1  .3 


-  This  function  was  not 


implemented  due  to  the  time  constraints  placed  upon  the 
project  and  the  relatively  low  priority  placed  upon  this 
requirement  (  ref  para  2. 2. 4.1  ). 


5.2.1 .4 


-  This  function  was  not 


implemented  for  the  same  reasons  given  in  para  5. 2. 1.3  (  ref 
para  2.2.4  .2  ) . 


5.2.1 .5 


-  This  function  was 


implemented  for  the  same  reasons  given  in  para  5. 2. 1.3  (  ref 
para  2.2.4 .3  ) . 


5.2.1 .6 


-  This 


function  was  envisioned  to  have  included  real-time  control 
over  configuration  modification  [1:67].  The  actual 
implementation,  however,  does  not  allow  the  operator  to 
interactively  modify  any  system  parameter  or  database  status 
variable. 


This  function  is  minimally  addressed  with  the  operator 
ability  to  display  the  status  of  select  database  tables  and 
variables  (  ref  para  4.4.1.17  and  Appendix  F  ). 


Branch  testing  was  applied  to  all  branches  of  the 
program  which  could  be  reached  using  keyboard  inputs.  These 
branches  included  all  of  the  terminal  concentrator  functions 


.r 


(  ie.  -  interrupt  handling,  buffering,  output,  etc.  ). 
However,  the  DMA  servicing  code  could  not  be  reached  nor 
tested  due  to  the  host's  inability  to  generate  or  receive 
DMA  traffic. 

5. 2. 2.1  Support  for  LCN  Study  -  Although  this  function 
passed  its  testing  (  ref  Table  5-1  ),  one  limitation  was 
revealed.  This  limitation  appears  to  be  caused  by  a  coding 
deficiency  in  the  LFMLHI.C  library  program.  This  program 
(  ref  para  4. 3. 2. 2  )  contains  the  ’C»  run-time  utilities 
used  for  file  manipulation  - —  among  which,  is  the  "fclose" 
subroutine  used  to  close  the  "LSIFEP.DAT"  accounting  file. 

This  subroutine  fills  a  memory  buffer  with  data 
intended  for  a  disk  file.  When  the  buffer  is  full,  it  is 
flushed  and  written  to  disk.  During  normal  processing,  this 
presents  no  problem.  However,  upon  system  termination,  the 
"LFEPLO.C"  program  issues  the  "fclose"  subroutine  call  to 
close  the  accounting  file  (  ref  para  4.4.1.24  ).  Testing 
revealed  that  the  "fclose"  subroutine  does  not  flush  the 
partially  filled  memory  buffer  prior  to  closing  the  file. 
Therefore,  any  recorded  data  which  is  memory  resident  at 
system  termination  will  not  be  written  to  disk. 

Another  problem  may  exist  during  accounting  file  disk 
writes.  The  source  code  ensures  that  a  large  enough  block 
of  free  disk  area  is  available  before  opening  the 


"LSIFEP.DAT"  file.  However,  this  file  grows  dynamically  and 
its  size  depends  upon  terminal  traffic  intensity.  It  is  not 
readily  apparent  what  happens  when  the  bottom  of  the 
"LSIFEP. DAT”  file  butts  up  against  the  front  of  an  existing 
file.  Further  investigation  should  be  conducted  to  validate 

that  the  "LSIFEP.DAT"  file  does  not  grow  without  bound  - 

and  there-by  overwrite  any  existing  files. 


5.3  Summary  - 

This  chapter  described  the  testing  methodologies  used 
to  validate  the  LSI  FEP  software.  In  it,  the 
requirements-based  testing  and  program-based  testing 
strategies  were  defined.  The  results  of  both  testing 
approaches  on  the  LSI  FEP  software  were  discussed. 
Limitations  of  the  testing  phase  were  described  and 
generally  attributed  to  the  lack  of  a  VAX/VMS  supported 
device  driver  for  the  DMA  interface. 


One  potential  source  for  the  driver  had  been  located 
and  efforts  were  underway  to  procure  the  driver  from  that 


CHAPTER  6 


CONCLUSION 


6.1  The  Problem  Revisited 

The  problem  investigated  during  this  project  was  to 
design,  implement,  and  document  the  LSI-11/23  portion  of  the 
Communications  Front  End  Processor  (FEP)  system  (  ref  para 
1.3  ). 

This  investigation  began  with  an  analysis  of  the 
functional  requirements  which  included  prioritizing  the 
requirements  for  the  purpose  of  ordering  the  implemention 
effort.  Design  decisions  and  tradeoffs  were  examined  in  the 
light  of  these  priority  assignments.  Next,  network  design 
Issues  were  discussed  using  the  ISO  Reference  Model  as  a 
departure  point  for  the  protocol  layers.  Software  design 
and  implementation  issues  were  then  considered  with 


capabilities  and  limitations  examined  and  the  software 
structure  defined. 


This  investigation  ended  with  a  test  and  evaluation 
phase  conducted  using  both  requireraents-based  and 
program-based  testing  methods. 


6.2  Accomplishments  - 

Specific  accomplishments  of  this  thesis  effort  can  be 
classified  as  either  hardware  or  software  improvements. 

6.2.1  Hardware  Improvements  - 

The  major  hardware  improvement  was  the  physical 
placement  of  the  DMA  interlink  boards  within  the  VAX-11/780 
and  LSI-11/23  computers  and  connecting  these  boards  via  the 
DMA  cabling.  Other  accomplishments  included  insertion  of 
the  four  serial  port  DLV11-J  card  (  ref  para  2 . 3  •  4  )  and 
replacement  of  the  two  standard  M8044  Plessey  memory  boards 
(together  addressing  memory  locations  0  -  377777  octal)  with 
a  single  MSV11-E  [20:468-487]  card  which  allowed  full 
LSI-11/23  addressing  from  0-777777  octal. 


Software  improvements  included  accomplishment  of  the 


middle  phases  -  Design,  Coding,  and  Testing  -  of  the 
Software  Development  Life  Cycle  model  (  ref  para  1.5.1  ). 
These  phases  proceeded  from  the  Requirements  Analysis  and 
Specification  phases  accomplished  in  a  previous  [1]  thesis 
effort. 

Specific  software  enhancements  included  the  coding  and 
testing  of  the  Terminal  Concentration  (  ref  Chapter  4  ) 
features  as  well  as  the  Accounting  data  recording  features 
for  the  Local  Computer  Network  study  requirement.  Code  was 
written  to  service  the  LSI-11/23  end  of  the  DMA  interface, 
but  resources  were  not  available  to  test  this  software. 


6.3  Discussion  - 

This  section  summarizes  the  thesis  investigation  from 
the  point  of  view  of  designer  and  iraplementer.  Presentation 
chronacles  the  problems  (and  resolutions)  that  occurred  at 
various  points. 

6 .3  .1  Scope  - 


The  first  hard  decision  to  be  made  was  limiting  the 
scope  of  this  investigation  to  implementing  the  LSI-11/23 


portion  of  the  FEP  system.  There  is  a  tendency  for  every 
builder  to  want  to  create  an  entity  which  is  complete  unto 
itself.  It  is  very  difficult  to  confine  oneself  to  building 
a  piece  of  some  whole  that  will  not  be  realized  for  some 
time.  This  project  provided  the  challenge  of  paring  the  FEP 
implemetation  down  to  a  size  for  which  a  realistic  effort 
could  be  expected  to  produce  a  reasonable  chance  of  success. 

6.3.2  Requirements  Prioritization  - 

One  of  the  early  major  decisions  concerned  assigning 
certain  requirements  into  the  low  priority  category  (  ref 
para  2.2.4  ).  Early  expectations  were  that  all  but  the  low 
priority  functions  would  be  implemented.  Tagging  a  function 
as  low  priority  was,  in  effect,  passing-the-buck  for  its 
ultimate  implementation  to  a  follow-on  thesis  investigation. 
It  was  paramount,  therefore,  that  the  "nice  to  have" 
functions  be  properly  identified  and  placed  in  the  low 
priority  class. 

6.3.3  Design  Decisions  and  Tradeoffs  - 

Decisions  made  immediately  after  function  priority 
selection  shaped  and  molded  the  rest  of  the  implementation 
effort.  These  design  decisions  provided  the  guiding 
framework  which  gave  eventual  direction  to  the  software 
coding.  Each  decision  funneled  the  next  issue  into  an 
..ncreasingly  narrow  path  toward  resolution.  It  was 


imperative  that  the  early  design  decisions  be  correct 
because  flexibility  for  change  grew  smaller  with  each 
successive  decision. 


6.3.4  Network  Design  and. Protocol  Issues  - 

The  network  design  was  accomplished  at  too  early  a 
stage  in  the  project.  It  proceeded  from  a  traditional 
network  approach  and  resulted  in  what  may  be  an 
over-designed  network.  The  primary  reason  for  this  was 
that,  at  this  early  point  in  the  project,  the  capabilities 
and  requirements  of  the  Able  Computer  Technology,  Inc. 
Interlink  DMA  interface  were  not  fully  understood. 

Even  now,  any  increased  knowledge  felt  by  the  author  in 
this  respect  continues  to  exist  only  as  a  subjective  opinion 
which  cannot  be  put  to  the  test  until  a  host  device  driver 
becomes  operationally  available.  For  this  reason.  Chapter  3 
was  allowed  to  remain  as  written  and  its  evaluation  deferred 
pending  arrival  of  the  testing  tools. 

6.3.5  Software  Design  and  Implemen.ta_ti.aii  - 

Chapter  4  chronicled  a  period  of  time  in  which  author 
experienced  the  alternating  extremes  of  exhilarating 
satisfaction  and  nagging  frustration.  In  several  instances, 
critical  code  fragments  that  were  expected  to  require  many 
rewrites  worked  flawlessly  the  first  time.  On  other 


occasions,  errors  which  were  as  dumb  as  they  were 
transparent  delayed  the  project  for  days. 


6.3.6 


It  seems  that  no  matter  how  strenuously  one  advocates 
testing  as  a  cycle-long  requirement,  it  always  seems  to  be 
deferred  until  finally  addressed  at  the  eleventh  hour  of  a 
software  project.  Although  top-  down  implementation  of  the 
code  segments  protects  against  this  to  a  large  degree,  it 
does  not  completely  eliminate  this  panic  mode  of  testing. 
Throughout  this  implementation,  testing  seemed  to  lag  behind 
production,  followed  only  by  documentation  in  the  race  of 
procrastinations. 


6.4  Recommendations  - 


Several  concrete  recommendations  emerged  from  this 
study  as  follows: 


6.4.1 


Without  a  working  device  driver  on  the  host  (VAX)  end 
of  the  DMA  link,  this  project  would  seem  to  be  incomplete. 
As  stated  in  Chapter  5,  a  potential  DR-11B  device  driver  has 
been  located  and  and  a  copy  of  the  driver  source  code  has 
been  requested  from  the  writer.  This  driver  currently  only 


-  Ill  - 


handles  word  mode  data  transfers  for  the  VAX-11/780  and 
would  have  to  be  modified  to  provide  the  expanded 
capabilities  of  block  mode  transfers  for  the  FEP 
application. 

This  modification  does  not  appear  to  be  a  trivial 
exercise.  A  firm  grasp  of  the  VAX  assembly  instruction  set 
and  I/O  data  base  will  be  required  as  well  as  a  good 
understanding  of  the  DMA  programming. 

The  driver  should  be  examined  upon  arrival  and  modified 
by  a  qualified  programmer  to  address  the  needs  of  the  VAX 
FEP. 

6.4.2  Data  Link  Protocol  - 

As  stated  in  Chapter  5,  the  Data  Link  Protocol  was  not 
implemented  primarily  due  to  the  uncertainty  of  its 
requirement.  This  aspect  should  be  further  investigated 
once  the  DR-1  IB  driver  becomes  operational. 

6.4.3  BaLfQr  Sissons  - 

The  program  buffer  sizes  C200  characters  for  terminal 


traffic  and  2000  characters  for  node  traffic)  were  chosen 
arbitrarily  (  ref  para  3. 3. 3. 3  and  para  3. 3. 4.1  ).  These 
sizes  may  be  adjusted  based  upon  further  testing. 


At  present,  the  LSI  FEP  will  support  seven  dedicated 
VT-100  interactive  terminals  and  one  VT-100  terminal  which 
can  operate  as  the  SOC  or  as  the  eighth  interactive 


terminal.  The  requirements  specify  that  this  configuration 
should  be  expandable  to  sixteen  terminals.  The  LSI-11/23 
unibus  structure  should  be  further  investigated  to  ensure 
that  enough  I/O  port  addresses  and  interrupt  vectors  exist 
for  this  expansion. 

6.4.5  LFMLHI.C  File  Manipulation  Limitation  - 

As  discussed  in  Chapter  5,  the  "fclose"  function  does 
not  flush  the  memory  buffer  of  data  destined  for  disk 
writing  prior  to  closing  the  file.  This  deficiency  should 
be  corrected.  At  the  same  time,  thv  potential  'write 
without  bound'  question  posed  in  Chapter  5  should  also  be 
investigated. 

6.4.6  The  Completed  DEL  FEP  - 

Finally,  the  whole  to  which  this  thesis  effort  is  only 
a  part  should  be  concluded.  Namely,  the  remaining  VAX  FEP 
software  should  be  designed  and  implemented.  In  addition, 
the  low  priority  tasks  (deferred  from  implementation  in  this 
thesis)  should  be  re-examined  and  implemented. 
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6- 8 


I/O . 2-12,  2-15,  2-18, 

2-20  to  2-22,  2-24,  4-11 

InChar . 4-5,  4-8,  4-10,  4-12, 

4-16  to  4-18 

ISO . 3-4 


LCN . 

LFEPHI.C  . 

LFEPIO.C  . 

LFEPL0.C  . 

LFMLHI.C  . 

LFMLHI.MAC  . 

LFMLLO.MAC  . 

LLM . 

LPM . . 

LSI . 


2- 2,  2-4,  2-10,  4-23 
4-9,  4-21 

4-7 

4- 8,  4-21 ,  5-8 

5- 8 

4-8  to  4-9 
4-8 

3- 2,  3-4,  3-7  to  3-9 
3-2 

2-1,  2-3,  2-6,  2-8  to  2-13, 
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2-15  to  2-16,  2-19  to  2-20, 

2- 24  to  2-28,  3-2, 

3- 8  to  3-9,  3-11,  3-14, 

4- 1  to  4-2,  4-6  to  4-9,  4-12 
4-15,  4-17,  4-19, 

4- 21  to  4-24,  5-5  to  5-6, 

5- 9,  6-1  to  6-3 

LSIFEP.C . 4-5 

LSIFEP.DAT  .  4-10,  4-21,  4-23,  5-8  to  5-9 

LSIFEP.SAV . 4-7 

LSIFEX.SAV . 4-6  to  4-7 

LSM . 3-2 

LTM . 3-2,  3-7 

MMU . 2-21  ,  2-24 

MSV11-E . 6-2 


NBT . 4-6,  4-10,  4-14,  4-17,  4-19, 

4-22 

NBUFF.MAC . 4-7  to  4-8 

NodeChar . 4-6.  4-8,  4-10,  4-14, 

4-18  to  4-20 

OutChar . 4-5,  4-8,  4-10,  4-18,  4-20 

PAD . 3-7 

PARI . 4-7,  4-9 

PID . 3-11 

PM-MFV1 1 A . 2-8  to  2-9,  2-20 

PST . 4-6,  4-10  to  4-11,  4-17, 

4-19  to  4-20,  4-22 

PSW . 4-11,  4-21 

RBUF . 2-15  to  2-16,  4-11 

RCSR . 4-11 

RS232  .  2-8 

RT-11  . .  2-6,  2-14,  2-21  to  2-22, 

2-24,  4-4,  4-6,  4-21 

RT11SJ . 4-6 

RT11XM . 4-6,  4-10  to  4-11 

SJ . 2-14 

SLP . 3-2 

SOC . 2-20,  3-2  to  3-3, 

4-9  to  4-12,  4-14  to  4-15, 
4-17,  4-19  to  4-23 
STDIO.H . 4-7 

TBUFF.MAC . 4-8 

TDM . 3-5 
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THT . 4-6,  4-18 

TID . 3-11  4-11  ,  4-19 

TTxDMA . 4-19  to  4-20 

UNIBUS . 2-20 

VAX . 2-2  to  2-3,  2-6  to  2-8,  2-10, 

2- 12,  2-20,  2-24,  3-2  to  3-3, 

3- 9,  3-11,  5-6,  5-9,  6-2,  6-8 

VLM . 3-3  to  3-4,  3-7,  3-9 

VMS  . . 2-3,  2-6,  2-8,  3-3,  5-6,  5-9 

VPM . 3-3 

VSM . 3-3 

VT-100 . 2-7,  2-19,  3-13 

XBUF . 2-16  to  2-17,  4-11,  4-18 

XCSR . 2-16  to  2-17,  4-11,  4-18 

XM . 2-14,  2-21  to  2-22, 

2-24  to  2-25 
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APPENDIX  A 


SOFTWARE  REQUIREMENTS  ANALYSIS 


This  appendix  reproduces  the  Designer 
Software  Sub-System  Requirements  indentified 
This  model  served  as  the  departure  point  upon 
current  thesis  effort  progressed. 


Perspective 
in  ref  [ 1 ] . 
which  the 


Requirement 


Description 


1.1 
1  .2 
1.3 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1.3.1 
1 .3.1 
1.3.1 
1.3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1.3.1 
1 .3.1 
1.3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1.3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1 .3.1 
1.3.1 


.1 

.1 .1 
.1  .1 .1 
.1 .1 .2 
.1 .2 
.1 .2.1 
.1  .2.1  .1 
.1  .2.1  .2 
.1  .2.2 
.1  .2.2.1 
.1  .3 
.1  .3.1 
.1  .3.1  .1 
.1  .3.1  .2 
.1  .3.1  .3 
.1 .3.1  .4 
.1  .3.2 
.1  .3.2.1 
.1 .3.3 
.1  .3.3.1 
.1 .3.3.1 .1 
.1 .3.3.1 .2 
.1 .3.3.1 .3 
.1 .3.3.1 .4 
.1 .3.3.2 
.1  .3. 3. 2.1 
.1  .3. 3.2. 2 
.1 .3. 3. 2. 3 
.1 .3. 3. 2. 4 
.1 .3. 3. 2. 5 
.1 .3. 3. 2. 6 
.1  .3. 3. 2. 7 
.1 .3. 3.2. 8 
.1 .3. 3. 2. 9 


Local  Computer  Network 
Two  Processors 
Communications  Link 
Software  On  Each  Processor 
Front-End  Software 

Support  User  Terminals 
Virtual  Link 

Packet  Interlock 
Sequence  Number 
Information  Routing 
Logical  Link 
Same  Processor 
Between  Processors 
Physical  Link 

Between  Processors 
Message  Assembly/Disassembly 
Header 

Source  Terminal 
Destination  Terminal 
Message  Number 
Message  Length 
Message  Text 

Alpha-numeric  Characters 
Transmission  Protocol 
Logical  Link 
Source  Node 
Destination  Node 
Message  Number 
Queue  Control  Information 
Physical  Link 

Source  Processor 

Destination  Processor 

Message  Sequence 

Link  Mode 

Queue  Length 

Message  Space 

Queue  Control  Information 

Checkf ield 

Message  Terminator 


Requirement 


Description 


1 .3.1 .1  .4 
1  .3.1  .1  .4.1 

1 .3.1 .1  .4.2 

1 .3.1  .2 

1 .3.1  .2.1 
1  .3.1  .2.2 
1  .3.1  .3 

1 .3.1 .3.1 

1 .3.1 .3.1 .1 

1 .3.1 .3.1 .2 

1  .3.1 .3.1 .2.1 
1  .3.1 .3.1  .2.2 
1 .3.1  .3.2 

1 .3.1 .3.3 
1 .3.1  .3.4 
1 .3.1  .3.5 

1 .3.1  .3.6 

1 .3.2 

1  .3.2.1 
1  .3.2.1  .1 
1 .3.2.1  .1 .1 
1 .3.2.1  .1  .2 
1  .3.2.1  .2 
1 .3.2.1  .2.1 
1 .3.2.1  .2.1  .1 
1  .3.2.1  .2.1  .2 
1  .3.2.1  .2.2 
1.3. 2.1  .2.2.1 
1  .3.2.1  .3 
1  .3.2.1  .3.1 
1 .3.2.1  .3.1  .1 
1 .3.2.1  .3.1 .2 
1  .3.2.1  .3.1  .3 
1  .3.2.1  .3.1  .4 
1  .3.2.1  .3.2 

1 .3.2.1  .3.2.1 
1  .3.2.1  .3.3 

1 .3.2.1 .3.3.1 

1.3. 2. 1.3. 3. 1.1 

1 .3.2.1  .3.3.1  .2 

1 .3.2.1 .3.3.1 .3 
1 .3.2.1  .3.3.1 .4 


Link  Assignment  Strategy 
Multiple  Links 
Multiple  Link  Types 
Perform  User  Tasks 

Operating  System  Tasks 
Special  Functions 
Comm  Link  Management 
Control  Comm  Link 
Physical  Control 
Link  Mode 

Message  Mode 
File  Mode 

Assemble  Comm  Link  Message 
Transmit  Comm  Link  Message 
Receive  Comm  Link  Message 
Disassemble  Comm  Link  Message 
Error  Check  Messages 
Host  Software 

Support  User  Terminals 
Virtual  Link 

Packet  Interlock 
Sequence  Number 
Information  Routing 
Logical  Link 
Same  Processor 
Between  Processors 
Physical  Link 

Between  Processors 
Message  Assembly/Disassembly 
Header 

Source  Terminal 
Destination  Terminal 
Message  Number 
Message  Length 
Message  Text 

Alpha-numeric  Characters 
Transmission  Protocol 
Logical  Link 
Source  Node 
Destination  Node 
Message  Number 
Queue  Control  Information 


Requirement 


Description 


1 .3 .2 .1 .3 .3 .2  Physical  Link 

1 .3.2.1 .3 *3  .2.1  Source  Processor 

1 .3 .2.1 .3 .3 .2.2  Destination  Processor 

1 .3 .2 .1 .3 .3 .2 .3  Message  Sequence 

1 .3.2.1  .3. 3  .2. 4  Link  Mode 

1 .3.2.1 .3. 3. 2. 5  Queue  Length 

1 .3 .2 .1  .3 .3 .2 .6  Message  Space 

1 .3 .2 .1 .3 .3 .2 .7  Queue  Control  Information 

1 .3.2.1  .3. 3. 2. 8  Checkf  ield 

1 .3  .2 .1 .3  .3 .2 .9  Message  Terminator 

1 .3.2.1  .4  Link  Assignment  Strategy 

1.3. 2. 1.4.1  Multiple  Links 

1.3. 2. 1.4. 2  Multiple  Link  Types 

1 .3.2.2  Perform  User  Tasks 

1.3. 2. 2.1  Operating  System  Tasks 

1.3. 2. 2. 2  Special  Functions 

1  .3.2.3  Comm  Link  Management 

1.3. 2. 3.1  Control  Comm  Link 

1.3. 2. 3. 1.1  Physical  Control 

1  .3. 2. 3.1  .2  Link  Mode 

1 .3 .2.3 .1 .2.1  Message  Mode 

1  .3 .2 .3 .1 .2  .2  File  Mode 

1.3. 2. 3. 2  Assemble  Comm  Link  Message 

1.3. 2. 3. 3  Transmit  Comm  Link  Message 

1.3. 2. 3. 4  Receive  Comm  Link  Message 

1.3. 2. 3. 5  Disassemble  Comm  Link  Message 

1.3. 2. 3. 6  Error  Check  Messages 

2  Host  Operating  System 

2.1  Multi-Programmed  Environment 

2.2  Mass  Storage 

2.3  Comm  Link  Support 

2.4  High  Level  Language 

3  FEP  Operating  System 

3.1  Support  for  Maximum  Terminal  Population 

3.2  Mass  Storage 

3.3  Comm  Link  Support 

3.4  High  Level  Language 


Requirement 


Description 


4 

4.1 

4.2 

4.2.1 

4.2.2 

4. 2. 2.1 

4. 2. 2. 2 

4. 2. 2. 3 

4.3 

4.3.1 

4.3.2 

4. 3. 2.1 

4.4 

4.4.1 
4.4.1  .1 
4.4.1  .2 

4.4.1  .3 

4.5 

4.5.1 

4.5.2 


Consistent  User  Interface 

Provide  "Single  User"  Environment 
Consistent  With  VAX/VMS  Operation 
Single-User/Host  Operations 
Control/Management  Operations 
Terminal  CONNECT 
Terminal  DISCONNECT 
Command  Interpreter 
Procedural  Assistance 

Single-User/Host  Operations 
Control/Management  Operations 
HELP  Operation 
Easy  to  Learn  and  Use 

Control/Management  Operations 
HELP  Operation 
Terminal  CONNECT 
Terminal  DISCONNECT 
Processing  Support  Invisible  to  User 
Single-User/Host  Operations 
Control/Management  Operations 


c? 


5 

5.1 

5.1.1 

5.1  .2 

5.1  .3 

5.2 

5.2.1 
5.2.1  .1 
5.2.1  .2 

5.2.1 .3 

5.2.1 .3.1 

5.2.1  .3.1  .1 

5.2.1 .3.1  .2 
5.2.1 .3.2 
5.2.1  .3.2.1 
5.2.1  .3.2.2 

5.2.1 .3.2.3 

5.2.1  .3.3 

5.2.1 .3.3.1 

5.2.1 .3.3.2 

5.2.2 

5.2.3 


Operating  Environment  Compatibility 
Physical  Plant  Compatibility 
Power  Source 
Temperature  Range 
Humidity  Range 
Academic  Compatibility 
Unattended  Operation 
Startup  Procedure 
Shutdown  Procedure 

Asynchronous  Intermediate  Processing 
User  Level  Messages 
Requests 
Responses 

System  Level  Messages 

Entries  From  FEP  Console 
Responses  to  System  Requests 
System  Level  Status 
Queueing  System 

Servers:  Logical  Nodes 
Message  Movement  Strategy 
Support  for  8  Interactive  Terminals 
Support  for  Line  Printer 
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Requirement 


Description 


5.2.4 

Support  for  Study  of  LCN 

5. 2. 4.1 

Collect  Performance  Data 

5. 2. 4.1  .1 

System  Level  Status 

5. 2. 4.1  .1  .1 

Queue  Overflow 

5. 2. 4.1  .1  .2 

Comm  Link  Errors 

5. 2. 4.1 .2 

Terminal  Session  Statistics 

5. 2. 4.1  .2.1 

Session  Number 

5. 2. 4.1  .2.2 

Terminal  Number 

5. 2. 4.1  .2.3 

Connect  Date 

5. 2. 4.1  .2.4 

Connect  Time 

5. 2. 4.1  .2.5 

Disconnect  Date 

5. 2. 4.1  .2.6 

Disconnect  Time 

5. 2. 4.1  .2.7 

First  User  File  Record 

5. 2. 4.1 .2.8 

Last  User  File  Record 

5. 2. 4.1  .3 

User  Session  Statistics 

5. 2. 4.1  .3.1 

User  Record  Number 

5. 2. 4.1  .3.2 

Session  Number 

5. 2. 4.1  .3.3 

Username 

5. 2. 4.1  .3.4 

Current  System 

5  .2.4.1  .3.5 

Logon  Time 

5. 2. 4.1 .3.6 

Logoff  Time 

5. 2. 4.1  .3.7 

Number  Messages  Input 

5. 2. 4.1  .3.8 

Number  Characters  Input 

5. 2. 4.1  .3.9 

Number  Messages  Output 

5. 2. 4.1  .3.10 

Number  Characters  Output 

5. 2. 4.1  .3.11 

Number  Messages  Sent  to  Printer 

5. 2. 4.1 .3.12 

Number  Characters  Sent  to  Printer 

5. 2. 4.1  .3.13 

Total  Printer  Time 

5. 2. 4.1  .3.14 

Total  Number  Printers  Assigned 

5. 2. 4.1  .4 

System  Queue  Statistics 

5. 2. 4.1  .4.1 

Queue  Name 

5. 2. 4.1  .4.2 

Current  Length 

5. 2. 4.1  .4.3 

Message  Number 

5. 2. 4.1  .4.4 

Event  Time 

5. 2. 4.1  .4.5 

Event  Code 

5. 2. 4. 2 

File  Transfer 

5. 2. 4. 2.1 

Transfer  To/From  Host 

5 .2. 4. 2. 2 

Disk  Media 

5  .2.4.3 

Peripheral  Sharing 

5. 2. 4. 3.1 

Route  Output  To  Printer 

5.2.5 

DELNET  Integration 

5. 2. 5.1 

Single-User/DELNET  Operations 

5. 2. 5. 2 

Control/Management  Operations 

/  ^  ✓ 


Requirement 


6 

6.1 
6.1 .1 
6.1  .2 
6.2 
6.2.1 
6.2.1  .1 
6.2.1  .2 
6.2.1  .3 
6.2.1 .4 
6.2.2 
6. 2. 2.1 
6. 2. 2. 2 

6. 2. 2. 3 

6.2.3 

6.2.4 


Description 


Supportability 

In-House  Maintenance 
Hardware 
Software 
Expansion 

Modular  Software 
Functions 

Functionally  Cohesive 
Hierarchical  Structure 
Loosely  Coupled 
Physical  Configuration 
Terminals 
Processors 
Comm  Links 

Inspect  Configuration 
Modify  Configuration 

Minimum  Cost 

On-hand  Components 

Data  Security 
No  Requirement 


o  o 
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Initialize  ! 
PST  ! 
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1.1  I 
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{  Initialize  ! 
!  Interrupts  ! 

i  ! 

!  1 .2  I 

i _ : 


i  =  index  into  PST 


!  Initialize 
I  Interrupts 


Service 

Terminal 

Interrupts 

1 .2.x 


\ 

i\ 

ll\ 

I  *  I  \ 


-  i  i 
\ ! 

:  1 1 : 1 1 

1 ...... 

\ 

111!!! 

1 

Milll 

]  _ 

Mill 

1 

\l  1 1 

1  Ml 

j 

_ M 

Service 

DMA 

Interrupts 
1 .2.9 


8  copies: 

1  for  each  VT-100 
(  expandable  to  16  ) 


NOTE:  Dotted  lines  indicate  that  interrupt 
service  routines  are  ACTIVATED  by 
module  1 .2  rather  than  CALLED 
directly.  Interrupt  service  routines 
are  INVOKED  by  the  RT11XM  operating 
system  upon  hardware  detection  of  an 
I/O  interrupt. 
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I  Perform 
!  Normal 
I  Activities 
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1 
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Serv ice 

Node 

Queues 


i  r  index  into  PST 
n  =  index  into  NBT 


I 


I  Gather  I 

I  Statistics  ! 

I  ! 

I  I 

!\  X.7  i 

l_\ _ I 


a  s  address  of  THT 
r  =  reason  for  gathering  statistics 
(  1  =  entry  into  a  node  queue  ) 


Build  ! 
Transport  | 
Header  t 


TTx-to-DMA  | 
Output  j 
I 

2.3.1  I 
_ I 


I  DMA-to-TTx 
I  Output 
I 

I  2.3.2 

I _ 


i  =  index  into  PST 


%u 


TTx-to-DMA 

Output 

2.3.1 


r  =  2 


1  Gather 
}  Statistics 


a  s  address  of  message  in  NodeChar 
r  s  reason  for  gathering  statistics 
(  2  s  exit  from  a  node  queue  ) 


B-1 0 


address  of  message  in  NodeChar 
reason  for  gathering  statistics 
(  2  =  exit  from  a  node  queue  ) 


APPENDIX  C 

LSI  FEP  DATA  DICTIONARY 


This  data  dictionary  is  divided  into  two  parts.  The 
first  part  is  a  dictionary  of  global  data  items  and 
structures  (  Data  Item  Entries  begin  on  page  C-2  )  from 
program  LFEPLO.C  while  the  second  part  is  a  dictionary  of 
functional  modules  (  Functional  Modules  begin  on  page  C-20  ) 
from  the  same  program.  Each  part  contains  a  short 
introduction  and  a  table  of  contents  for  the  section. 


C.1 


This  section  contains  those  data  items  and  entries 
which  are  global  in  nature  -  that  is,  they  are  referenced  by 
more  than  one  program  module. 


Paragraph 

Data  Item 

Page 

C.1 

Data  Item  Entries  (Heading) 

C-  2 

C.1  .1 

AbortFlag 

C-  3 

C.1  .2 

DMABusyFlag 

C-  4 

C.1  .3 

DMAwc 

C-  5 

C.1  .4 

Endldx 

C-  6 

C.1  .5 

FileOpenFlag 

C-  7 

C.1 .6 

GoDMAFlag 

C-  8 

C.1  .7 

InChar 

C-  9 

C.1 .8 

LastMsgSeqNbr 

C-10 

C.1  .9 

NBT 

C-1 1 

C.1  .10 

NBTCharCount 

C-1 2 

C.1  .11 

NodeChar 

C-1 3 

C.1  .12 

Out Char 

C-1 4 

C.1  .13 

PST 

C-1 5 

C.1  .14 

PSTCharCount 

C-1 6 

C.1  .15 

Startldx 

C-17 

C.1  .16 

Stopldx 

C-1  8 

C.1 .17 

THT 

C-1 9 

WWW 


X 


C. 1 . ?  DMAwc 

Item  Name: 

DMAwc 

Data  Type: 

Integer 

Item  Size: 

2  bytes 

Where 

written: 

! 

Where  read 

DMAInterruptServiceRoutine  !  DMAInterruptServiceRoutine 

j  SetUpForlnputDMA 


Description:  DMAwc  is  used  to  store  the  word  count  of 

the  current  DMA  block  transfer. 


's'. 
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C.1.4  m  - 


Item 

Name: 

Endldx 

Data 

Type : 

Integer 

Item 

Size: 

2  bytes 

Where  written: 


Where  read: 


SrvNodeQueue 


Description: 


TTxtoDMAOutput 

DMAtoTTxTransfer 


Endldx  is  used  as  an  index  into  the 
NBT  to  mark  the  array  element  offset 
of  the  last  character  to  be  moved 
in  the  current  message. 


C-6 


C.1.7  InChar 


Item  Name: 
Data  Type: 
Item  Size: 


InChar 

array 

1800  bytes 


Where  written: 


SOCInterrupt Service Routine 
T1 InterruptServiceRoutine 
T2InterruptServiceRoutine 
T3 InterruptServiceRoutine 
T4InterruptServiceRoutine 
T5 InterruptServiceRoutine 
T6InterruptServiceRoutine 
T7InterruptServiceRoutine 
SetUpForlnputDMA 


I  Where  read: 

I _ 

I 

'  SrvInputQueue 
!  EvalSOCInput 
j  MoveMsgtoNodeTTxDMA 


I 


Description:  InChar  is  an  1800  element  array  of 

characters.  InChar  is  partitioned  by 
each  of  the  9  entries  in  PST  yielding 
an  input  buffer  size  of  200  chars 
for  each  port. 


Item 

Name: 

NBT 

Data 

Type: 

structure 

Item 

Size: 

24  bytes 

Where 

written: 

I 

Where  read 

InitSystem 

PerfNormalActivities 
MoveMsgtoNodeTTxDMA 
SrvNodeQueue 
TTxtoDMAOutput 
DMAtoTTxTransf er 


1  InitSyaytem 
I  PerfNormalActivities 
I  SrvInpuQueue 
!  MoveMsgtoNodeTTxDMA 
!  BldTransportHeader 
I  SrvNodeQueue 
!  TTxtoDMAOutput 
{  DMAtoTTxTransfer 


Description: 


The  Node  Buffer  Table  (  NBT  )  is 
a  global  communication  structure 
through  which  several  subroutines 
can  manage  the  NodeChar  buffer 
transactions. 


BldTransportHeader 


Description: 


I  SrvInputQueue 
!  BldTransportHeader 
I  SrvNodeQueue 


NBTCharCount  is  the  message  character 
count  used  for  messages  residing 
in  character  array  NodeChar. 
NBTCharCount  is  always  an  even 
number  because  the  DMA  transfer 
protocol  requires  word  (  2  bytes  ) 
transfers  and  messages  residing  in 
NodeChar  are  either  headed  for  the 
DMA  or  have  just  been  received 
via  DMA. 
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Item  Name: 


NodeChar 


Data  Type: 
Item  Size: 


array 

4000  bytes 


Where  written: 


MoveMsgtoNodeTTxDMA 


Where  read: 


I  SrvNodeQueue 
!  TTxtoDMAOutput 
i  DMAtoTTxTransf er 


Description: 


NodeChar  As  a  4000  element  character 
array  which  contains  complete 
messages  headed  for  (  or  received 
from  )  the  DMA  interface.  It  is 
partitioned  by  the  2  entries  in 
NBT  into  2000  character  buffers, 
one  for  each  of  the  2  node  queues. 
Pointers  into  NodeChar  are 
maintained  in  the  structure  NBT. 
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Item  Name: 

OutChar 

Data  Type: 

array 

Item  Size: 

1800  bytes 

Where 

written: 

1 

1 

Where  read: 

DMAtoTTxTransfer 

» 

1 

1 

J 

SrvOutputQueue 

Description: 

OutChar  is 

an 

1800  element  character 

array  partitioned  by  the  9  entries 
of  the  PST  into  200  character 
buffers  for  each  of  the  9  ports. 
OutChar  contains  characters  to  be 
displayed  upon  the  terminal  screen 
of  the  respective  port  console. 
OutChar  pointers  are  maintained  in 
structure  PST. 
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i 

j 

a 
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V 
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C.1  .13  £S1  - 


Item  Name:  PST 


Data  Type:  structure 

Item  Size:  604  bytes 


Where  written: 


Where  read: 


InitSystem 

InitPST 

Initlnterrupts 
Per f Normal Activities 
EvalSOCInput 
MoveMsgtoNodeTTxDMA 
SrvOutputQueue 
DMAtoTTxTransf er 
SOCInterrupt Service Routine 
T1 InterruptServiceRoutine 
T2InterruptServiceRoutine 
T3 InterruptServiceRoutine 
T4 Interrupt Service Routine 
T5 InterruptServiceRoutine 
T6InterruptServiceRoutine 
T7InterruptServiceRoutine 
SetUpForlnputDMA 


'  InitSystem 
!  InitPST 
{  Initlnterrupts 
I  Perf NormalActi vities 
!  SrvInpuQueue 
j  EvalSOCInput 
!  MoveMsgtoNodeTTxDMA 
!  BldTransportHeader 
'  SrvOutputQueue 
'  SrvNodeQueue 
i  DMAtoTTxTransf er 
!  TermSystem 

!  SOCInterruptServiceRoutine 
i  T1 InterruptServiceRoutine 
i  T2InterruptServiceRoutine 
!  T3InterruptServiceRoutine 
I  T4InterruptServiceRoutine 
i  T5InterruptServiceRoutine 
!  T6InterruptServiceRoutine 
i  TTInterruptServiceRoutine 
I  SetUpForlnputDMA 


Description:  The  Port  Status  Table  (  PST  )  is 

9  entry  global  communication  structure 
through  which  several  subroutines 
can  manage  the  InChar  and  OutChar 
buffer  transactions.  Also,  PST 
contains  the  port  addresses  of  each 
port  as  well  as  the  addresses  of 
the  interrupt  vectors  and  interrupt 
service  routines. 


m 


C.1.14  PSTCharCount  - 

Item  Name: 

PSTCharCount 

Data  Type: 

Integer 

Item  Size: 

2  bytes 

Where 

written:  { 

1 

1 

Where  read: 

SrvInputQueue 

1 

1 

1 

1 

1 

1 

1 

SrvInputQueue 

MoveMsgtoNodeTTxDMA 

Description:  PSTCharCount  is  a  character  count 

representing  the  size  (in  bytes)  of  an 
input  request.  This  size  includes 
the  number  of  characters  typed  on  the 
keyboard  as  well  as  the  size  of  the 
Transport  Header  which  is  appended 
to  the  front  of  the  message  prior 
to  message  movement  into  the  TTxDMA 
node  queue.  PSTCharCount  (unlike 
NBTCharCount)  may  be  an  odd  number. 


& 
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C.1  .15 


Item  Name: 


Startldx 


Data  Type: 


Integer 


Item  Size: 


2  bytes 


Where  written: 


Where  read 


SrvInputQueue 

j  SrvInputQueue 
'  EvalSOCInput 

i 

i 

Description: 

Startldx  is  a  temporary  variable 
used  primarily  to  calculate, 
along  with  Stopldx,  the 
size  (character  count)  of  the 

current  input  request  from 
a  terminal  operator.  It  is  set 
equal  to  the  current  position 
of  the  PST  InChar  'get'  index 
and  remains  unchanged  (while 
the  ’get1  index  increments) 
throughout  processing  of  the 
current  request. 

c.i  .16  ?,tgp;ux  - 

Item  Name: 

Stopldx 

Data  Type: 

Integer 

Item  Size: 

2  bytes 

Where 

written: 

1 

Where  read 

SrvInputQueue 


SrvInputQueue 

EvalSOCInput 


Description: 


Stopldx  is  a  temporary  variable 
used  primarily  to  calculate, 
along  with  Startldx,  the 
size  (character  count)  of  the 
current  input  request  from 
a  terminal  operator.  It  is 
initially  set  equal  to  Startldx 
and  increments  as  each  character 
in  InChar  is  scanned.  When  a 
carriage  return  is  encountered 
in  InChar,  Startldx  is  subtracted 
from  Stopldx  to  yield  the  number 
of  characters  in  the  input  string 


Item  Name: 


THT 


Data  Type:  structure 

Item  Size:  36  bytes 


Where  written:  I  Where  read: 

_ ! _ 

I 

BldTransportHeader  !  MoveMsgtoNodeTTxDMA 

i  SrvNodeQueue 


Description:  The  Transport  Header  Table  (  THT  ) 

is  a  36  character  structure  used 
as  a  template  to  form  the  message 
Transport  Header  (para.  ) 

which  is  appended  to  the  beginning 
of  each  DMA-bound  input  request. 
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This  section  contains  a  brief  PDL  description  of  the 
processing  logic  in  each  LFEPLO.C  functional  module. 


Para 

Module  Nbr 

Module  Name 

Page 

C.2 

Functional  Modules  (Heading) 

C-20 

C.2.1 

0 

Main 

C-21 

C.2. 2 

1 

InitSystera 

C-22 

C.2. 3 

1 .1 

InitPST 

C-23 

C.2. 4 

1  .2 

Initlnterrupts 

C-24 

C.2. 5 

1  .2.1 

SOCInterruptServiceRoutine 

C-25 

C.2. 6 

1 .2.2 

T1 InterruptServiceRoutine 

C-27 
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1 .2.3 

T2 Interrupt Service Routine 

C-28 

C.2. 8 

1  .2.4 

T3 Interrupt Service Routine 

C-29 

C.2. 9 

1  .2.5 

T4 Interrupt Service Routine 

C-30 

C.2. 10 

1  .2.6 

T5 InterruptServiceRoutine 
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C.2. 11 

1  .2.7 

T6InterruptServieeRoutine 

C-32 

C.2. 12 

1  .2.8 

T7InterruptServiceRoutine 

C-33 

C.2. 13 

1.2.9 

DMAInterruptServiceRoutine 

C-34 

C.2. 14 

1  .2.9.1 

SetUpForlnputDMA 

C-36 

C.2. 15 

2 

Perf Normal Activities 

C-37 

C.2. 16 

2.1 

SrvInputQueue 

C-38 

C.2. 17 

2.1  .1 

EvalSOCInput 

C-40 
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2.1  .2 

MoveMsgtoNodeTTxDMA 

C-41 

C.2. 19 

2.1  .2.1 

BldTransportHeader 

C-42 

C.2. 20 

2.2 

SrvOutputQueue 

C-43 

C.2. 21 

2.3 

SrvNodeQueue 

C-44 

C.2. 22 

2.3.1 

TTxtoDMAOutput 

C-45 

C.2. 23 

2.3.2 

DMAtoTTxOutput 

C-46 

C.2. 24 

3 

TermSystem 
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C.2.1  Main  - 


Called  From: 


»C*  Shell 


Modules  Called:  1  InitSystem 

2  Perf NormalActivities 

3  TermSystem 

Globals  Read:  N/A 

Globals  Written:  N/A 


PDL  Description: 


CALL  InitSystem  to  initialize  the  system 

CALL  Perf Normal Activities  to  conduct  normal  activities 

CALL  TermSystem  to  effect  an  orderly  return  to  RT11XM 
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Module  Number:  1 

Called  From:  0  Main 

Modules  Called:  1.1  InitPST 

1.2  Initlnterrupts 

Globals  Read:  NBROFBUFFERS 

NBROFPORTS 

NBT 

NODEBUFFERSIZE 

PST 

TERMBUFFERSIZE 

Globals  Written:  DMABusyFlag 

FileOpenFlag 

NBT 

PST 


PDL  Description: 

set  DMA  Busy  Flag  =  not  busy  status 

if  the  accounting  file  can  be  opened 

set  the  File  Open  Flag  =  File  is  open 

else 

set  the  File  Open  Flag  =  File  is  not  open 
display  an  error  message  to  the  SOC 

for  all  9  entries  in  the  Port  Status  Table 
initialize  the  4  InChar  indexes 
initialize  the  4  OutChar  indexes 

for  both  entries  in  the  Node  Buffer  Table 
initialize  the  4  NodeChar  indexes 

designate  NBT  entry  0  as  "TTx" 
designate  NBT  entry  1  as  "DMA" 

fetch  the  addrs  of  the  Interrupt  Service  Routines 

CALL  InitPST  ()  -  to  further  initialize  the  PST 

for  all  9  I/O  ports 

CALL  Initlnterrupts  ()  -  to  activate  interrupts 


c.2.3  InliEST  - 

Module  Number: 


Called  From: 


1  InitSystem 


Modules  Called:  N/A 


Globals  Read: 


BLANK8 

DMAINTVECTOR 

DMAPORTADDR 

FIRSTPORT 

FIRSTVECTOR 

NBROFPORTS 

NBROFTERMINALS 

PORTOFFSET 

PST 

SOCINTVECTOR 

SOCPORTADDR 

VECTOROFFSET 


Globals  Written:  PST 


PDL  Description: 


for  all  PST  entries: 
init  Terminal  ID 
init  Port  Addr 
init  Interrupt  vector 
init  Terminal  Mode 
init  Process  ID 
init  Process  Name 


C.2.4 


Module  Number: 
Called  From: 
Modules  Called: 
Globals  Read: 

Globals  Written: 


1 .2 

1  InitSystem 

N/A 

DMA 

DMACSR 

PST 

PST 


PDL  Description: 

set  new  interrupt  PSW  mask  =  340  (octal) 

save  current  port  interrupt  PSW  mask 
save  current  port  interrupt  vector 

set  current  port  interrupt  mask  =  new  interrupt  PSW  mask 
set  current  port  interrupt  vector  =  PST  interrupt  vector 
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C.2. 5  SOCInterruptSer vice Routine  - 
Module  Number:  1.2.1 


Called  From: 

Activated  from: 
Modules  Called: 
Globals  Read: 


hardware  interrupt 
(  vector  addr :  000060 
port  addr:  777560  ) 


1.2 

N/A 


Initlnterrupts 


BACKSPACE 

CR 

CTRLC 

DEL 

LF 

SPACE 

InChar 

PST 

YES 


Globals  Written:  AbortFlag 

InChar 

PST 


PDL  Description: 

CALL  entint  to  save  machine  registers 

move  char  from  data  port  to  InChar  buffer 

echo  char  to  console  screen 

if  input  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 

casentry  --  input  char 

case  Control  C  ( ~C) 

set  the  system  abort  flag  =  YES 

case  Delete  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 
over-write  console  char  with  a  space 
back-space  the  console  cursor 

case  default 

increment  the  InChar  "put"  index 
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Hoi, 


Module  Number: 


1 .2.2 


Called  From: 

hardware  interrupt 
(  vector  addr:  000300 

port  addr:  776500 

Activated  from: 

1.2  Initlnterrupts 

Modules  Called: 

N/A 

Globals  Read: 

BACKSPACE 

s 

CR 

DEL 

LF 

SPACE 

InChar 

PST 

Globals  Written 

:  InChar 

PST 

PDL  Description 

• 

• 

CALL  entint  to 

save  machine  registers 

move  char  from  data  port  to  InChar  buffer 

echo  char  to  console  screen 

if  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 

if  char  was  the  "delete"  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 
over-write  console  char  with  a  space 
back-space  the  console  cursor 

else 

increment  the  InChar  "put"  index 
if  InChar  "put"  index  exceeds  buffer  limit 
decrement  InChar  "put"  index 

CALL  retint  to  restore  machine  registers 


C.2.7  T2 Interrupt Service Rout in 


Module  Number: 

1 .2.3 

Called  From: 

hardware 

interrupt 

(  vector 

addr : 

000310 

port 

addr : 

776510 

Activated  from: 

1.2  Initlnterrupts 

Modules  Called: 

N/A 

Globals  Read: 

BACKSPACE 

CR 

DEL 

LF 

SPACE 

InChar 

PST 

Globals  Written: 

InChar 

PST 

PDL  Description: 

CALL  entint  to  save  machine  registers 

move  char  from  data  port  to  InChar  buffer 
echo  char  to  console  screen 

if  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 

if  char  was  the  "delete"  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 

over-write  console  char  with  a  space 
back-space  the  console  cursor 

else 

increment  the  InChar  "put"  index 
if  InChar  "put"  index  exceeds  buffer  limit 
decrement  InChar  "put"  index 

CALL  retint  to  restore  machine  registers 


ii! 


Module  Number: 


1 .2.4 


Called  From: 


hardware  interrupt 
(  vector  addr:  000320 
port  addr:  776520  ) 


Activated  from:  1.2  Initlnterrupts 
Modules  Called:  N/A 


Globals  Read: 


BACKSPACE 

CR 

DEL 

LF 

SPACE 

InChar 

PST 


Globals  Written: 


InChar 

PST 


PDL  Description: 

CALL  entint  to  save  machine  registers 

move  char  from  data  port  to  InChar  buffer 
echo  char  to  console  screen 

if  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 


if  char  was  the  "delete"  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 
over-write  console  char  with  a  space 
back-space  the  console  cursor 


else 


increment  the  InChar  "put"  index 
if  InChar  "put"  index  exceeds  buffer  limit 
decrement  InChar  "put"  index 


CALL  retint  to  restore  machine  registers 
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C.2.9  T4 Interrupt Service Routine  - 


Module  Number: 

1 .2.5 

Called  From: 

hardware  interrupt 
(  vector  addr:  000340 

port  addr:  776540 

Activated  from: 

1 .2  Initlnterrupts 

Modules  Called: 

N/A 

Globals  Read: 

BACKSPACE 

CR 

DEL 

LF 

SPACE 

InChar 

PST 

Globals  Written: 

InChar 

PST 

PDL  Description: 

CALL  entint  to  save  machine  registers 

move  char  from  data  port  to  InChar  buffer 

echo  char  to  console  screen 

if  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 

if  char  was  the  "delete”  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 
over-write  console  char  with  a  space 
back-space  the  console  cursor 

else 

increment  the  InChar  "put"  index 
if  InChar  "put"  index  exceeds  buffer  limit 
decrement  InChar  "put"  index 


CALL  retint  to  restore  machine  registers 


C.2.10  T5 Interrupt Service Routine  - 


Module  Number: 

1 .2.6 

Called  From: 

hardware  interrupt 
(  vector  addr:  000350 

port  addr:  776550 

Activated  from: 

1 .2  Initlnterrupts 

Modules  Called: 

N/A 

Globals  Read: 

BACKSPACE 

CR 

DEL 

LF 

SPACE 

InChar 

PST 

Globals  Written: 

InChar 

PST 

PDL  Description: 

CALL  entint  to  save  machine  registers 

move  char  from  data  port  to  InChar  buffer 

echo  char  to  console  screen 

if  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 

if  char  was  the  "delete”  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 
over-write  console  char  with  a  space 
back-space  the  console  cursor 

else 

increment  the  InChar  "put"  index 
if  InChar  "put"  index  exceeds  buffer  limit 
decrement  InChar  "put"  index 


CALL  retint  to  restore  machine  registers 


C.2.11 


Module  Number: 
Called  From: 


1 .2.7 

hardware  interrupt 
(  vector  addr:  000360 
port  addr:  776560  ) 


Activated  from:  1.2  Initlnterrupts 
Modules  Called:  N/A 


Globals  Read: 


BACKSPACE 

CR 

DEL 

LF 

SPACE 

InChar 

PST 


Globals  Written:  InChar 


PDL  Description: 

CALL  entint  to  save  machine  registers 

move  char  from  data  port  to  InChar  buffer 
echo  char  to  console  screen 

if  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 


if  char  was  the  "delete"  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 
over-write  console  char  with  a  space 
back-space  the  console  cursor 

else 

increment  the  InChar  "put"  index 
if  InChar  "put"  index  exceeds  buffer  limit 
decrement  InChar  "put"  index 

CALL  retint  to  restore  machine  registers 
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Module  Number: 


1 .2.8 


Called  From:  hardware  interrupt 

(  vector  addr:  000370 
port  addr:  776570  ) 


Activated  from: 

1 .2  Initlnterrupts 

Modules  Called: 

N/A 

Globals  Read: 

BACKSPACE 

CR 

DEL 

LF 

SPACE 

InChar 

PST 

Globals  Written: 

InChar 

PST 

PDL  Description: 

CALL  entint  to  save  machine  registers 

move  char  from  data  port  to  InChar  buffer 

echo  char  to  console  screen 

if  char  was  a  carriage  return 

echo  a  line  feed  to  the  console  screen 

if  char  was  the  "delete"  key 

if  this  is  not  the  first  char 

decrement  the  InChar  "put"  index 
back-space  the  console  cursor 
over-write  console  char  with  a  space 
back-space  the  console  cursor 

else 

increment  the  InChar  "put"  index 
if  InChar  "put"  index  exceeds  buffer  limit 
decrement  InChar  "put"  index 

CALL  retint  to  restore  machine  registers 


C.2.13  DMAInterruptServ ice Routine 
Module  Number:  1.2.9 


Called  From: 

hardware  interrupt 
(  vector  addr:  000124 
port  addr:  772410  ) 

Activated  from: 

1.2  Initlnterrupts 

Modules  Called: 

1.2. 9.1  SetUpForlnputDMA 

Globals  Read: 

DMABAR 

DMACSR 

DMADBR 

DM  AGO 

DMAIREQUEST 

DMANEX 

DMAODIRECTION 

DMA0M0DE 

DMAWCR 

DMABusyFlag 

DM  Awe 

NBT 

NodeChar 

Globals  Written: 

DMABusyFlag 

DM  Awe 

NBT 

NodeChar 

PDL  Description: 

CALL  entint  to  save  machine  registers 

if  a  non-existant  memory  address  was  referenced 
display  a  SOC  alert 

else 

if  this  is  a  host  input  request 

CALL  SetUpForlnputDMA  to  service  the  request 

else 

casentry  ~  status  of  the  DMA-busy  flag 
case  1  (input,  word  mode  expected) 
fetch  the  word  count  from  the  host 
if  enough  room  in  node  queue  for  msg 
set  DMA-busy  flag  =  2 
set  DMA  Base  Addr  register 
set  DMA  Word  Count  register 
set  DM ACS R  Output  Direction 


set  DMACSR  Output  Mode 
set  DMACSR  Go  bit 

else 

display  SOC  alert 

case  2  (input,  block  mode  expected) 
case  3  (output,  word  mode  in  progress) 
case  4  (output,  block  mode  in  progress) 
endcase 

CALL  retint  to  restore  machine  registers 


C.2.14  SetUpForlnPutDMA  - 


Module  Number: 
Called  From: 


1 .2.9.1 

1.2.9  DMAInterruptServiceRoutine 


Modules  Called:  N/A 


S3 

I 


Globals  Read: 


DMA 

DMABAR 

DMACSR 

DMAIMODE 

DMAOMODE 

DMAWCR 

DMABusyFlag 

DMAwc 

InChar 

PST 


Globals  Written:  DMABusyFlag 

PST 


IV? 


PDL  Description: 

set  DMA-busy  flag  =  input  (word  mode)  expected 
set  up  DMA  Base  address  register 

if  DMA  request  is  for  "word”  mode 

set  DMA  output  mode  to  "word"  mode 
set  DMA  word  count  =  1 

else 

set  DMA  output  mode  to  "block"  mode 

set  DMA  word  count  =  requested  word  count 

set  DMA-busy  flag  r  input  (block  mode)  expected 
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C.2.1 5  PerfN' 
Module  Number: 


Called  From: 


0  Main 


Modules  Called:  2.1  SrvInputQueue 

2.2  SrvOutputQueue 

2.3  SrvNodeQueue 


Globals  Read: 


AbortFlag 

NBROFBUFFERS 

NBROFPORTS 

NBT 

NO 

PST 


\m 


Globals  Written:  NBT 

PST 


PDL  Description: 


display  "FEP  Activated"  console  alert 
display  activation  time 

while  the  abort  flag  remains  cleared 

for  all  Input  Queues 

if  input  chars  are  queued 
CALL  SrvInputQueue 
else 

re-initialize  pointers 

for  all  Output  Queues 

if  output  chars  are  queued 
CALL  SrvOutputQueue 

else 

re-initialize  pointers 

for  all  Node  Queues 

if  node  chars  are  queued 
CALL  SrvNodeQueue 

else 

re-initialize  pointers 


C-37 


,  W\  •*.  •*.  T.  - 


Module  Number 


2.1 


Called  From:  2  Perf NormalActivities 

Modules  Called:  2.1.1  EvalSOCInput 

2.1.2  MoveMsgtoNodeTTxDMA 

Globals  Read:  CR 

DMA 

DMATTx 

GoDMAFlag 

InChar 

NBT 

NBTCharCount 

PST 

PSTCharCount 

SOC 

Startldx 

Stopldx 

THTSIZE 

TTxDMA 

Globals  Written:  GoDMAFlag 

NBT 

NBTCharCount 

PST 

PSTCharCount 

Startldx 

Stopldx 


PDL  Description: 

while  Input  Queue  chars  remain  to  be  evaluated 

if  the  char  is  a  carriage  return  or 
the  terminal  is  in  character  mode 

if  input  was  from  SOC 
CALL  EvalSOCInput 
set  node  index  for  outbound  DMA 

else 

if  input  was  from  DMA 

set  node  index  for  inbound  DMA 

else 

set  node  index  for  outbound  DMA 

if  chars  are  to  be  moved  to  DMA 

calculate  the  message  size  (chars) 


Module  Number: 


2.1.1 


Called  From:  2.1  SrvInputQueue 

Modules  Called:  N/A 

Globals  Read:  GoDMAFlag 

InChar 

NBT 

NO 

PST 

SOC 

Startldx 

Stopldx 

YES 

Globals  Written:  GoDMAFlag 

PST 


PDL  Description: 

Assume  no  DMA  output  is  to  occur 

if  input  request  is  to  display  the  PST 
CALL  DispPST 

else 

if  input  request  is  to  display  the  NBT 
CALL  DispNBT 

else 

if  input  request  is  to  display  time 
CALL  DispTime 

else 

set  DMA-output-is-to-occur  flag 

if  this  current  input  is  a  display  request 

adjust  fetch  pointer  for  next  input  message 


Module  Number:  2.1.2 


Called  From:  2.1  SrvInputQueue 

Modules  Called:  2. 1.2.1  BldTranspor tHeader 

Globals  Read:  InChar 

LF 

NBT 

NodeChar 

PSTCharCount 

PST 

THT 

THTSIZE 

Globals  Written:  NBT 

NodeChar 

PST 


PDL  Description: 

CALL  BldTransportHeader  for  current  message 

for  each  character  to  be  moved  to  the  node  queue 

if  the  char  is  part  of  the  Transport  Header 
move  char  from  THT  to  NodeChar 

else 

move  char  from  InChar  to  NodeChar 

if  message  contains  an  odd  number  of  chars 

pad  message  with  a  trailing  line  feed  char 


CALL  GatherStats  to  trap  node  queue  accounting  data 


Module  Number: 


2.1  .2.1 


Called  From:  2.1 .2  MoveMsgtoNodeTTxDMA 

Modules  Called:  N/A 

Globals  Read:  MAXMSGSEQNBR 

ZBTERM 

ZEROS 

LastMsgSeqNbr 

NBT 

NBTCharCount 

PST 


Globals  Written:  LastMsgSeqNbr 

THT 


PDL  Description: 

copy  process  name  from  PST  to  THT 
copy  process  ID  from  PST  to  THT 
copy  terminal  ID  from  PST  to  THT 
copy  terminal  mode  from  PST  to  THT 

increment  the  last  message  sequence  number 

if  last  message  sequence  number  exceeds  limit 
set  last  message  sequence  number  =  0 

copy  ascii  value  of  last  message  sequence  number  to  THT 

set  the  multi-packet  flag  in  THT  =  character  1  N* 

copy  ascii  value  of  msg  char  count  to  THT 

set  multi-packet  sequence  number  in  THT  =  *00* 

copy  originating  node  name  from  NBT  to  THT 

copy  a  zero  byte  delimiter  to  THT 


Module  Number: 
Called  From: 
Modules  Called: 
Globals  Read: 

Globals  Written: 


2.2 

2  Perf NormalActi vities 

N/A 


OutChar 

PST 

PST 


PDL  Description: 

if  output  port  is  ready  for  next  character 

move  next  char  from  OutChar  to  output  data  port 
increment  the  OutChar  "get"  pointer 


if  the  OutChar  "get"  pointer  exceeds  high  limit 
set  OutChar  "get”  pointer  to  low  limit 


C.2.21  SrvNode( 

3ueue  - 

Module  Number: 

2.3 

Called  From: 

2  Perf NormalActivities 

Modules  Called: 

2.3.1  TTxToDMAOutput 

2.3.2  DMAtoTTxOutput 

Globals  Read: 

NBROFPORTS 

TTxDMA 

NBT 

NBTCharCount 

NodeChar 

PST 

Globals  Written: 

Endldx 

NBT 

NBTCharCount 

PDL  Description: 

While  chars  remain  in  the  queue 

Do  for  each  entry  (port)  in  the  PST 

CALL  strcompare  to  match  terminal  ID  with  msg  header 
if  the  msg  in  the  queue  is  for  this  terminal  user 
get  msg  char  count  from  Transport  header 
convert  this  ascii  count  to  an  integer 
set  Endldx  =  NodeChar  index  of  the  last  char 
if  the  queue  being  serviced  is  TTx-to-DMA 

CALL  TTxtoDMAOutput  to  request  DMA  transfer 

else 

CALL  DMAtoTTxOutput  to  move  msg  to  OutChar 

if  strcompare  could  find  no  matching  terminal  ID 

display  an  error  alert  upon  the  SOC  terminal  screen 
display  the  msg  contents  on  the  SOC  terminal  screen 
flush  entire  node  buffer  by  resetting  the  ’get'  ptr 


C.2.22  TTxtoDMAOutPU 
Module  Number:  2.3.1 


JSHI 


Called  From: 


2.3  SrvNodeQueue 


Modules  Called:  N/A 


Globals  Read: 


DM ACS R 
DMAREADY 
DMAODIRECTION 
DM AOMODE 
TTxDMA 

DMABusyFlag 

Endldx 

NBT 

NodeChar 


Globals  Written:  DMACSR 

DMADBR 

DMAODIRECTION 
DM AOMODE 

DMABusyFlag 

NBT 


PDL  Description: 

if  'word*  mode  input  is  expected  and  DMA  is  not  busy 
set  DMA  Base  Addr  register  =  block  word  count 
set  DMA  Output  mode  =  ’word’  mode 
set  DMA  Output  direction  =  LSI  is  transmitter 
set  DMA-busy  flag  =  Output  ’word’  mode  in  progress 

else 

display  an  error  alert  msg  upon  the  SOC  terminal  screen 
CALL  GatherStats  to  trap  node  queue  accounting  data 


C-45 


Module  Number: 


2.3.2 


Called  From: 
Modules  Called: 
Globals  Read: 


Globals  Written: 


2.3  SrvNodeQueue 
N/A 

DMATTx 

Endldx 

NBT 

NodeChar 

PST 

NBT 

OutChar 

PST 


PDL  Description: 


CALL  GatherStats  to  trap  node  queue  accounting  data 

while  NodeChar  characters  remain  for  this  message 
if  OutChar  ’put*  ■'ndex  <  high  limit 

copy  char  from  NodeChar  to  OutChar 
increment  NodeChar  pointer  to  next  char 
increment  OutChar  pointer  for  next  char 


Module  Number:  3 

Called  From:  0  Main 

Modules  Called:  N/A 

Globals  Read:  NBROFPORTS 

PST 

Globals  Written:  N/A 

PDL  Description: 

Do  for  all  PST  entries 

restore  original  interrupt  PWS  mask 
restore  original  interrupt  vector  address 

display  a  SOC  alert  that  the  FEP  system  has  been  aborted 

CALL  DispTime  to  display  the  time  of  abort 

CALL  DispElapsedTime  to  display  the  duration  of  FEP  processing 
CALL  fclose  to  close  the  accounting  file 


APPENDIX  D 

LSI  FEP  SOURCE  CODE  LISTINGS 


These  source  listings  represent  the  latest  versions 
of  the  LSI  FEP  programs  LFEPLO.C  and  LFEPHI.C.  Modules 
forming  LFEPLO.C  are  identified  by  module  numbers  containing 
purely  numerical  terms.  Modules  forming  LFEPHI.C  are 
identified  by  prefixing  the  numerical  part  with  the  ’X* 
character  representing  extended  memory  mapping. 


Table  of  Contents  for  A 


Module  Nbr 


Module  Name 


D .  1 

"LFEPLO.C" 

Program  Modules  (header) 

D-  3 

D.1  .1 

0 

Main 

D-  8 

D.1  .2 

1 

InitSystem 

D-  9 

D.1 .3 

1  .1 

InitPST 

D-1 1 

D.1  .4 

1  .2 

Initlnterrupts 

D-1 3 

D.1  .5 

2 

Perf Normal Activities 

D-1 4 

D.1  .6 

2.1 

SrvInputQueue 

D-16 

D.1  .7 

2.1  .1 

EvalSOCInput 

D-1  8 

D.1  .8 

2.1  .2 

MoveMsgtoNodeTTxDMA 

D-20 

D.1  .9 

2.1  .2.1 

BldTransportHeader 

D-22 

D.1  .10 

2.2 

SrvOutputQueue 

D-23 

D.1  .11 

2.3 

SrvNodeQueue 

D-24 

D.1  .12 

2.3.1 

TTxtoDMAOutput 

D-26 

D.1  .13 

2.3.2 

DMAtoTTxOutput 

D-27 

D.1  .14 

3 

TermSystem 

D-29 

D.1  .15 

1  .2.1 

SOCInterrupt Service Routine 

D-30 

D.1  .16 

1.2.2 

T1 InterruptServiceRoutine 

D-32 

D.1  .17 

1.2.3 

T2InterruptServiceRoutine 

D-34 

D.1  .18 

1.2.4 

T3 InterruptServiceRoutine 

D-36 

D.1  .19 

1.2.5 

T4InterruptServiceRoutine 

D-38 

D.1 .20 

1  .2.6 

T5 InterruptServiceRoutine 

D-40 

D.1 .21 

1 .2.7 

T6InterruptServiceRoutine 

D-42 

D.1 .22 

1 .2.8 

T7InterruptServiceRoutine 

D-44 

D.1 .23 

1.2.9 

DMAInterruptServiceRoutine 

D-46 

D.1  .24 

1  .2.9.1 

SetUpForlnputDMA 

D-48 

D.2 

"LFEPHI.C" 

Program  Modules  (header) 

D-49 

D.2.1 

X.1 

DispPST 

D-52 

D.2. 2 

X  .2 

DispNBT 

D-55 

D.2. 3 

X.3 

GetCurrentTime 

D-57 

D.2. 4 

X .  4 

DispTime 

D-59 

D.2. 5 

X.5 

CalcElapsedTirae 

D-60 

D.2. 6 

X.6 

DispElapsedTime 

D-62 

D.2. 7 

X.7 

GatherStats 

D-63 

D.1 

LFEPLO.C 

Program 

modules 

/##############*###*#**#*#**#*###*#*#***#*****#*******#********** 
*  * 

TITLE: 

LSI  FEP  Low  Memory  ' C*  Program 

* 

* 

FILENAME: 

LFEPLO.C 

DATE: 

3  Nov  83 

VERSION: 

A1 

OWNER: 

Capt  Allan 

F.  Masty 

COMPUTER 

SYSTEM: 

LSI-11/23 

OPERATING 

SYSTEM: 

RT11XM 

LANGUAGE: 

Telecon  'C 

t 

CONTENTS: 

0 

Main 

1 

InitSystem 

1.1 

InitPST 

1 .2 

Initlnterrupts 

* 

1 .2.1 

SOCInterruptServiceRoutine 

* 

1 .2.2 

T1  InterruptServiceRoutine 

* 

1.2.3 

T2InterruptServiceRoutine 

* 

1  .2.4 

T3 InterruptServiceRoutine 

* 

1  .2.5 

T4 InterruptServiceRoutine 

1 .2.6 

T5 InterruptServiceRoutine 

1 .2.7 

T6InterruptServiceRoutine 

1 .2.8 

T7Interrupt Service Routine 

* 

1 .2.9 

DMAInterruptServiceRoutine 

1 .2.9.1 

SetUpForlnputDMA 

2 

Perf Normal Activities 

2.1 

SrvInputQueue 

2.1  .1 

EvalSOCInput 

2.1  .2 

MoveMsgtoNodeTTxDMA 

2.1  .2.1 

BldTransportHeader 

2.2 

Srv Output Queue 

2.3 

SrvNodeQueue 

* 

2.3.1 

TTxtoDMAOutput 

2.3.2 

DMAtoTTxOutput 

3 

TermSystem 

FUNCTION: 

Performs  as  a  Communications  Front  End 

Processor 

(FEP)  for  a  DEC  VAX-11/780. 

Functions 

as  a  Terminal  Concentrator  in 

assembling 

and  routing  the  keyboard  and 

screen  traffic  for  8  (expandable  to  16) 

«•«§ 

DEC  VT-100 

terminals. 

* 

*/ 

gr 


GLOBALS 


/* 


*/ 


#def ine 

BACKSPACE 

*\010» 

/* 

Back-space  char  code 

*/ 

#def ine 

CR 

1 \01 5 ' 

/* 

Carriage  Return  char 

*/ 

#def ine 

CTRLC 

‘\003’ 

/* 

*C  (  control-C  )  char 

*/ 

#def ine 

DEL 

* \ 1 77 1 

/* 

"DELETE"  key  char  code 

*/ 

#def ine 

FIRSTPORT 

0176500 

/* 

First  LSI-11  port  addr 

*/ 

#define 

FIRSTVECTOR 

0000300 

/* 

First  int.  vector  addr 

*/ 

#def ine 

LF 

'  \01  2  * 

/* 

Line  Feed  character 

*/ 

#def ine 

MAXMSGSEQNBR 

0007777 

/* 

Largest  message  number 

*/ 

#def ine 

NO 

0 

/* 

BOOLEAN  variable 

*/ 

#def ine 

PORTOFFSET 

8 

/* 

8  word  port  seperations 

*/ 

#def ine 

SOCPORTADDR 

0177560 

/• 

I/O  port  addr  for  SOC 

*/ 

#def ine 

SOCINTVECTOR 

0000060 

/* 

SOC  Interrupt  vector  addr*/ 

#def ine 

SPACE 

»\040* 

/* 

Space  character  code 

*/ 

#define 

TERMBUFFERSIZE 

200 

/* 

Terminal  buffer  size 

*/ 

#def ine 

VECTOROFFSET 

8 

/« 

Interrupt  vector  spacing 

*/ 

#def ine 

YES 

1 

/* 

BOOLEAN  variable 

*/ 

extern 

char  InChar 

n  , 

/* 

Terminal  Input  Buffers 

*/ 

OutChar 

n  , 

/* 

Terminal  Output  Buffers 

*/ 

NodeChar 

n  ; 

/* 

Node-to-Node  Buffers 

*/ 

#include  "lfepio. 

h" 

/* 

Standard  10  routines 

*/ 

extern 

int  fopen  () 

• 

t 

int 

AbortFlag  =  NO  , 

/* 

BOOLEAN  for  aborting  FEP 

*/ 

DMABusyFlag  , 

/• 

Flag  set  when  the  DMA 

interface  is  busy  : 

0 

Not  Busy 

1 

DMA  word  input  expected 

2 

DMA  block  input  expected 

3  = 

DMA  word  output  pending 

4  = 

DMA  block  output  pending 

*/ 

DMAwc  , 

/* 

DMA  word  count  (block) 

*/ 

Endldx  , 

/* 

Used  in  servicing  NodeChar 

*/ 

FileOpenFlag  , 

/• 

Status  of  file  LSIFEP.DAT 

*/ 

GoDMAFlag  , 

/* 

BOOLEAN  to  send  DMA  output 

*/ 

Startldx  , 

/• 

Used  in  servicing  InChar 

*/ 

Stopldx  , 

/• 

Used  in  servicing  InChar 

*/ 

LastMsgSeqNbr  , 

/* 

Increments  for  each  new  msg 

*/ 

NBTCharCount  , 

/• 

Count  of  chars  in  NBT  msg 

*/ 

PSTCharCount  ; 

/* 

Count  of  chars  in  PST  msg 

*/ 

FILE  *fp  , 

•fopen  ()  ; 


D-4 


Port  Status  (  PS  )  Table  defines  &  declarations 


/*  . 

#def ine  NBROFPORTS 
#def ine  NBROFTERMINALS 
#define  SOC 

Idefine  T1 

#def ine  T2 

#define  T3 

#define  T4 

#define  T5 

#define  T6 

^define  T7 

^define  DMA 


/*  NBROFTERMINALS  +SOC  +DMA  */ 
/*  #  of  VT-100  terminals  */ 
/*  System  Operator’s  Console*/ 
/*  VT-100  unit  #1  */ 
/*  VT-100  unit  #2  */ 
/*  VT-100  unit  #3  */ 
/*  VT-100  unit  #4  */ 
/*  VT-100  unit  #5  */ 
/*  VT-100  unit  #6  */ 
/*  VT-100  unit  #7  */ 
/*  Direct  Memory  Access  */ 


struct  PortStatusDataRecord 

{ 

char  TID  [4]  ; 

char  TermMode  ; 


InLowIdx 

InPutldx 

InGetldx 

InHighldx 


OutLowIdx 

OutPutldx 

OutGetldx 

OutHighldx 


*RcvStatAddr  ; 
•RcvDataAddr  ; 
•TxmStatAddr  ; 
•TxmDataAddr  ; 


/*  VT-100  Terminal  ID  */ 

/*  line  or  character  mode  */ 

/*  Input  buffer  pointers  */ 


/*  Output  buffer  pointers  */ 


/*  receive  port  status  addr  */ 
/*  receive  port  data  addr  */ 
/*  transmit  port  status  addr*/ 
/*  transmit  port  data  addr  */ 


•IntVectAddr  ;  /*  receive  port  int.  addr  */ 

IntRoutineAddr  ;  /*  Interrupt  service  routine*/ 


int  St 
int  St 
} 

PST  [  NBROFPORTS  ] 


StorlntVect 

StorPSW 


/*  I/O  Port  Status  Table  (  PST  )  */ 


D-5 


index  DEFINES  for  node  -  to  -  node  buffers 


#def ine 
#def ine 


TTxDMA  0 
DMATTx  1 


/*  TTx  to  DMA  buffer 
/*  DMA  to  TTx  buffer 


misc  defines  for  Node  Buffer  table 


#def ine  NBROFBUFFERS 
#def ine  NODEBUFFERSIZE 


2  /*  Number  of  Node  buffers  */ 
2000  /*  #  of  chars  in  each  buffer*/ 


/*  ...  Node  Buffer  Table  declaration  . *, 

struct  NodeBuf ferRecord 

{ 

char  OrgNode  [4]  ; 

int  Lowldx  ; 

int  Putldx  ; 

int  Getldx  ; 

int  Highldx  ; 

} 

NBT  [  NBROFBUFFERS  ]  ;  /*  Node  Buffer  Table  (  NBT  )  */ 


struct  MsgTransportLayerHeader 


char 

char 

char 

char 

char 

} 


#def ine 


TID  [3]  ; 

Mode  ; 

MsgSeqNbr  [4]  ; 
MsgCharCnt  [4]  ; 
OrgNode  [3]  » 


/*  Transport  Header  Table  (  THT  )  */ 


THTSIZE  sizeof  (  THT  ) 


(4, 


J\ 


& 

V'/ 


/» 


Defines  for  DMA  control 


«/ 


K' 


$ 


© 


♦def ine 

DMAINTVECTOR 

0000124 

/* 

DMA 

interrupt  vector 

#def ine 

DMAPORTADDR 

0172410 

/* 

DMA 

start 

port 

address 

#def ine 

DMAWCR 

0172410 

/* 

DMA 

Word  Count 

Register 

#def ine 

DMABAR 

0172412 

/* 

DMA 

Bus  Address 

Register 

♦define 

DMACSR 

0172414 

/* 

DMA 

Control/Status  Reg 

#def ine 

DMADBR 

0172416 

/* 

DMA 

Data  Buffer 

Register 

/» 

/  •  •  • 

the  following 

define  bit 

settings 

in  DMACSR 

....  */ 

#def ine 

DMAGO 

0000001 

/• 

bit 

0 

V 

♦define 

DMAOMODE 

0000002 

/* 

bit 

1 

*/ 

♦define 

DMAODIRECTION 

0000004 

/* 

bit 

2 

V 

♦define 

DMAOREQUEST 

0000010 

/* 

bit 

3 

»/ 

/• 

bit 

4 

not 

used 

*/ 

/* 

bit 

5 

not 

used 

*/ 

♦define 

DMAIE 

0000100 

/* 

bit 

6 

*/ 

♦define 

DMAREADY 

0000200 

/• 

bit 

7 

*/ 

♦define 

DMACYCLE 

0000400 

/* 

bit 

8 

*/ 

♦define 

DMAIMODE 

0001000 

/* 

bit 

9 

»/ 

♦define 

DMAIDIRECTION 

0002000 

/* 

bit 

10 

*/ 

♦define 

DMAIREQUEST 

0004000 

/* 

bit 

11 

•/ 

/* 

bit 

12 

not 

used 

*/ 

/* 

bit 

13 

not 

used 

*/ 

♦define 

DM AN EX 

0040000 

/* 

bit 

14 

*/ 

♦define 

DMAERROR 

0100000 

/* 

bit 

15 

»/ 

•/ 

*/ 

*/ 

«/ 

»/ 


/  ** 


/a**#*##*#**#**#######***#***####**#**############*####**##,#*,# 


MODULE  NUMBER  /  NAME:  0  -  Main 


DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 


CALLING  MODULES: 


3  Nov  83  « 

A1  « 

Top  level  module  for  "LFEPLO.C"  * 
NONE  « 

NONE  * 

NONE  * 

NONE  * 

NONE  * 

NONE  * 

NONE  « 

NONE  * 

1  -  InitSystem  * 

2  -  Perf Normal Acivities  * 

3  -  TermSystem  * 

NONE  * 


AUTHOR: 

HISTORY: 


Capt  Allan  F.  Masty,  GCS-83D 
VSN  A1  -  3  November  1983 


Main  () 


{ 


InitSystem 

<)  ; 

/* 

First-time  processing 

»/ 

Perf NormalActivities  ()  ; 

/* 

Synchronous  processing 

•/ 

TermSystem 

()  ; 

/« 

Clean-up  routines 

«/ 

exit  (0); 

/« 

return  to  RT-11  monitor 

«/ 

D.  1  .2  InitSystem 


vi? 


/ft*************************************************************** 

* 


MODULE  NUMBER  /  NAME: 


1  -  InitSystem 


DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 


GLOBAL  TABLES  USED: 
GLOBAL  TABLES  CHANGED: 


FILES  READ: 
FILES  WRITTEN: 
MODULES  CALLED: 


CALLING  MODULES: 


* 

3  Nov  83  * 

A1  * 

Initializes  data  base  and  opens  * 
accounting  file  "LSIFEP.DAT". 

NONE 
NONE 
NONE 

DMABusyFlag 
FileOpenFlag 
NBT 
PST 
NBT 
PST 
NONE 
NONE 

1.1  -  InitPST 

1 .2  -  Initlnterrupts 

0  -  Main 


AUTHOR: 

HISTORY: 


Capt  Allan  F.  Masty,  GCS-83D 
VSN  A1  -  3  November  1983 


********* ************** ft ft*** **«*«*• ***********  *********  «***«*•*  / 


InitSystem  () 

{ 

int  i ; 


DMABusyFlag  =  0  ; 
FileOpenFlag  =  YES  ; 


/*  Loop  control  variable  */ 
/*  Input  word  [mode]  expected  */ 


if  (  (  fp  =  fopen  (  "LSIFEP.DAT",  "w"  )  )  =r  NULL  ) 
FileOpenFlag  =  NO  ; 

printf  ("\n  LSIFEP.DAT  cannot  be  opened.  \n"  )  ; 

} 


for  (  i 
{ 

PST 

=  0;  i  <  NBROFPORTS ; 

i++  ) 

[ i] .InLowIdx 

- 

i  * 

TERMBUFFERSIZE  ; 

PST 

[i]  .InPutldx 

PST 

[i]. InLowIdx  ; 

PST 

[ i]  .InGetldx 

= 

PST 

[i]. InLowIdx  ; 

PST 

[i]  .InHighldx 

= 

PST 

[ i ] .InLowIdx+TERMBUFFERSIZE-1 ; 

PST 

[ i] .OutLowIdx 

= 

i  * 

TERMBUFFERSIZE  ; 

PST 

[i] .OutPutldx 

PST 

[ i ] .OutLowIdx  ; 

vy 
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PST  [ i 3 .OutGetldx  =  PST  [ i ] .OutLowIdx  ; 

PST  [i] .OutHighldx  r  PST  [ i] .OutLowIdx+TERMBUFFERSIZE-1 

} 


for 


(  i 

{ 

NBT 

NBT 

NBT 

NBT 

} 


=  0;  i  <  NBROFBUFFERS;  i++  ) 


C i] .Lowldx 
[ i] .Putldx 
[i] .Getldx 
[ i] .Highldx 


=  i  *  NODEBUFFERSIZE  ; 

=  NBT  [i]. Lowldx  ; 

=  NBT  [i]. Lowldx  ; 

=  NBT  [ i] .LowIdx+NODEBUFFERSIZE-1 ; 


strcpy  (  NBT  [  TTxDMA  l.OrgNode,  "TTx"  )  ; 
strcpy  (  NBT  [  DMATTx  l.OrgNode,  "DMA”  )  ; 


PST  [SOC] .IntRoutineAddr  = 
PST  [  T1 ] .IntRoutineAddr  = 
PST  [  T2] .IntRoutineAddr  = 
PST  [  T33 .IntRoutineAddr  = 
PST  [  T4] .IntRoutineAddr  = 
PST  [  T53 .IntRoutineAddr  = 
PST  t  T6] .IntRoutineAddr  = 
PST  [  T73 .IntRoutineAddr  = 
PST  [DMA] .IntRoutineAddr  = 


SOCInterruptServiceRoutine 
T1 InterruptServiceRoutine 
T2InterruptServ ice Routine 
T3 Interrupt Service Routine 
T4Int err upt Service Routine 
T5 InterruptServiceRoutine 
T6 Interrupt Service Routine 
T7 InterruptServiceRoutine 
DM AInterrupt Service Routine 


InitPST  ()  ;  /*  Initialize  Port  Status  Table  */ 

Initlnterrupts  ()  ;  /*  Turn  on  all  interrupts  */ 


return  ; 


D.1.3  InitPST 


/#*»»*****#******»****#»#*##***#**»**#**#»*#*#*****##»»«**#****«• 

« 

» 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


1.1  -  InitPST 

3  Nov  83 
A1 

Completes  PST  initialization 

NONE 

NONE 

NONE 

NONE 

PST 

PST 

NONE 

NONE 

NONE 

1  -  InitSystem 
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***««*«***•*******•***•***«•****«*•««***«***«»*****««««*«««***» / 

InitPST  (  ) 


{ 


int 

i 

• 

9 

/* 

index 

strcpy 

( 

PST 

[SOC1.TID, 

"SOC" 

) 

strcpy 

( 

PST 

c 

T1  ] .TID, 

"T.1" 

) 

strcpy 

( 

PST 

[ 

T2] .TID, 

"T.2" 

) 

strcpy 

( 

PST 

[ 

T3] .TID, 

"T.3" 

) 

strcpy 

( 

PST 

[ 

T4] .TID, 

"T.4" 

) 

strcpy 

( 

PST 

[ 

T5J .TID, 

nT.5” 

) 

strcpy 

( 

PST 

c 

T6] .TID, 

nT.6n 

) 

strcpy 

( 

PST 

[ 

T7J .TID, 

"T.7” 

) 

strcpy 

( 

PST 

CDMA] .TID, 

"DMA" 

) 

for  (  i 

=  1; 

i 

<=  3;  i++  ) 

/• 

•/ 


VT-IOO’s  only  */ 

{ 

PST  [ i] .RcvStatAddr  =  FIRSTPORT  + 

(  ( i-1 )  *  PORTOFFSET  )  ; 

PST  [ i]  .IntVectAddr  =  FIRSTVECTOR  + 

(  (i-1)  *  VECTOROFFSET  )  ; 

} 


for  (  i  =  4;  i  <=  NBROFTERMINALS ;  i++  ) 

{ 


PST  [ i ]. RcvStatAddr 
PST  [ i]  .IntVectAddr 
} 

PST  [SOC] .RcvStatAddr 
PST  [SOC] .IntVectAddr 
PST  [DMA], RcvStatAddr 
PST  [DMA] .IntVectAddr 


=  FIRSTPORT  + 

(  i  *  PORTOFFSET  )  ; 

=  FIRSTVECTOR  + 

(  i  *  VECTOROFFSET  )  ; 


=  SOCPORTADDR 
=  SOCINTVECTOR 
=  DMAPORTADDR 
=  DMAINTVECTOR 


for  (  i  =  0  ;  i  <  NBROFPORTS ;  i++  ) 

{  /*  all  table  entries 

PST  [i] .TermMode  =  ’L’  ; 

PST  [i] .RcvDataAddr  =  PST  [ i] .RcvStatAddr  +  2 

PST  [ i] .TxmSta tAddr  =  PST  [ i] .RcvStatAddr  +  4 

PST  [i] .TxmDataAddr  =  PST  [ i] .RcvStatAddr  +  6 

} 


return  ; 


D.1.4  Initlnterrupts 

/a*##**##***##*##*##*#**#*###****##********#####****#*#********** 


MODULE  NUMBER  /  NAME: 


DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 


AUTHOR: 

HISTORY: 


1.2  -  Initlnterrupts 


3  Nov  83 
A1 

Enables  interrupts  for  all  PST 

entries 

NONE 

NONE 

NONE 

NONE 

PST 

PST 

NONE 

NONE 

NONE 

1  -  InitSystera 
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Initlnterrupts  (  ) 

{ 

int  i  ,  /*  index  into  PST  */ 

PSW  ,  /*  Processor  Status  Word  */ 

•temp  ;  /*  temporary  pointer  */ 

PSW  =  0000340  ;  /*  Interrupt  vector  PSW  */ 

for  (  i  =  0;  i  <  NBROFPORTS ;  i++  ) 

temp  s  PST  [ i] .IntVectAddr  ; 


PST  [i] .StorlntVect 
PST  [i] .StorPSW 
•PST  [ i] .IntVectAddr 
•(terap+1 ) 


*(  temp  )  ; 

»(temp+1)  ; 

PST  C i] .IntRoutineAddr  ; 
PSW  : 


if  (  i  <  DMA  )  /•  enable  interrupts  •/ 

•PST  [ i] .RcvStatAddr  =  0100  ; 

else 

•DMACSR  =  0100  ; 

} 


return 


D.1.5  Per f Normal Activities 


«»*»###«**»»»»«***«»»»*****#*******#***************** 

Perf NormalActivities  * 


/***«*««**•« 

«  MODULE  NUMBER  /  NAME: 

•  DATE: 

*  VERSION: 

«  FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 


CALLING  MODULES: 

AUTHOR: 

HISTORY: 


3  Nov  83 
A1 

Loops  and  scans  node  queues 
InChar,  OutChar,  and  NodeChar 
for  message  traffic  to  move. 
NONE 
NONE 

AbortFlag 

NONE 

NBT 

PST 

NBT 

PST 

NONE 

NONE 

X .  4  -  DispTime 

2.1  -  SrvInputQueue 

2.2  -  SrvOutputQueue 

2.3  -  SrvNodeQueue 

0  -  Main 
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»*H««*M««**>***«*»«««**»»*««*<**********,**,*****************/ 


Perf NormalActivities  () 


{ 

int  i 


/*  index  into  PST  or  NBT  */ 


printf  ("\n++++++++  FEP  Activated  at  ")  ; 


DispTime  ()  ; 

while  (  AbortFlag  ==  NO  ) 

for  (  i  =  NBROFPORTS  -  1  ;  i  >=  0;  i—  ) 

{  /*  Input  queue  scans  */ 

if  (  PST  [i] .InPutldx  ! =  PST  [i].InGetIdx  ) 
SrvInputQueue  (  i  )  ; 

else 


PST[i]. InPutldx  =  PST[ i] .InLowIdx  ; 


PST C i] .InGetldx  =  PST[ i] .InLowIdx  ; 

} 


for  (  i  =  NBROFPORTS  -  1;  i  >=  0;  i—  ) 

{  /*  Output  queue  scans  */ 

if  (  PST  [ i] .OutPutldx  !=  PST  [ i] .OutGetldx  ) 
SrvOutputQueue  (  i  )  ; 

else 

{ 

PST[i] .OutPutldx  =  PSTC i] .OutLowIdx  ; 

PST[ i] .OutGetldx  =  PST[ il .OutLowIdx  ; 

} 


for  (  i  =  NBROFBUFFERS  -1 ;  i  >=  0;  i—  ) 

{  /*  Node  buffer  scans  */ 

if  (  NBT  [il.Putldx  !=  NBT  [i].GetIdx  ) 
SrvNodeQueue  (  i  )  ; 

else 

{ 

NBT  [il.Putldx  =  NBT  [il.LowIdx  ; 

NBT  [il.Getldx  =  NBT  [il.LowIdx  ; 

} 

} 

} 

return  : 


D.1.6  SrvInputQueue 


/•*«««*«*******««***«***«*****«««**«**•*«««««««««««««*•*«**««**** 
*  « 


* 


MODULE  NUMBER  /  NAME: 

2.1  -  SrvInputQueue 

* 

DATE: 

3  Nov  83 

• 

VERSION: 

A1 

* 

FUNCTION: 

Moves  character  data  from  queue 

* 

InChar  to  queue  NodeChar. 

* 

INPUTS: 

i  =  index  into  PST 

* 

OUTPUTS: 

NONE 

* 

GLOBAL  VARIABLES  USED: 

GoDMAFlag 

* 

NBTCharCount 

• 

PSTCharCount 

* 

Startldx 

* 

Stopldx 

* 

GLOBAL  VARIABLES  CHANGED: 

GoDMAFlag 

* 

NBTCharCount 

* 

PSTCharCount 

* 

Startldx 

• 

Stopldx 

* 

GLOBAL  TABLES  USED: 

Inchar 

* 

NBT 

* 

PST 

* 

GLOBAL  TABLES  CHANGED: 

NBT 

* 

PST 

* 

FILES  READ: 

NONE 

* 

FILES  WRITTEN: 

NONE 

* 

MODULES  CALLED: 

2.1.1  -  EvalSOCInput 

* 

2.1.2  -  MoveMsgtoNodeTTxDMA 

CALLING  MODULES: 

2  -  Perf NormalActivities 

* 

AUTHOR: 

HISTORY: 
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SrvInputQueue  (  i  ) 

int  i  ;  /*  index  into  the  PST  */ 

{ 

Stopldx  =  Startldx  =  PST  [il.InGetldx  ; 

while  (  Stopldx  <  PST  [i].InPutIdx  ) 

if  (  (  InChar  [StopIdx++]  ==  CR)  I | 

(PST  [i] .TermMode  ==  »C')  ) 

{ 

if  (  i  ==  SOC  ) 
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EvalSOCInput  ()  ; 


if  (  GoDMAFlag++  )  /*  chars  to  be  moved  to  DMA  */ 

{ 

PSTCharCount  =  Stopldx  -  Startldx  +  THTSIZE  ; 
NBTCharCount  =  PSTCharCount  ; 

if  (  NBTCharCount  &  0000001  ) 

++NBTCharCount  ; 


} 

return 


if  ((  NBT  [TTxDMA] .Putldx  +  NBTCharCount  ) 

<=  NBT  [TTxDMA]. Highldx  ) 
MoveMsgtoNodeTTxDMA  (  i  )  ; 

else 


printf  ("\n  Node  %s  saturated. \n"f 

NBT  [TTxDMA] .OrgNode  )  ; 


/*  end  of  nifn  processing  */ 
/*  end  of  "while”  loop  */ 


D.1.7  EvalSOCInput 

/a***#*#*#*##**###*###**###*###*#***#*##**#*########***#*#*###*#* 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 


GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 


GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 


CALLING  MODULES: 

AUTHOR: 

HISTORY: 


2.1.1  -  EvalSOCInput 

3  Nov  83 
A1 

Displays  system  status  data  on 
System  Operator’s  Console  (SOC) 
request. 

NONE 

NONE 

GoDMAFlag 

Startldx 

Stopldx 

GoDMAFlag 

InChar 

NBT 

PST 

PST 

NONE 

NONE 

X.1  -  DispPST 

X.2  -  DispNBT 

X.4  -  DispTime 

2.1  -  SrvInputQueue 
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EvalSOCInput  () 

{ 

char  * 

int  z ; 

GoDMAFlag  =  NO  ; 


/*  assume  local  SOC  processing  */ 


p  s  4(  InChar  [Startldx]  )  ; 

if  (  strcorapare  ("pst”,  p,  3)  «  3  ) 

DispPST  (  &PST  )  ; 

else 

if  (  strcorapare  ("nbt",  p,  3)  ==  3  ) 
DispNBT  (  &NBT  )  ; 

else 

if  (  strcompare  ("time”,  p,  4)  s=  4  ) 

{ 
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printf  ("\nTime  =  ")  ; 

DispTime  ()  ; 
printf  (n\n")  ; 

else  /*  set  up  for  DMA  transfer  */ 

GoDMAFlag  =  YES  ; 

if  (  GoDMAFlag  ==  NO  ) 

PST  [SOC] .InGetldx  =  Stopldx  ; 

return  ; 
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D.1.8  MoveMsgtoNodeTTxDMA 


/##*#*»#**##****##*#**#####*****##*********#***##*****#**###***## 
«  * 

*  MODULE  NUMBER  /  NAME:  2.1.2  -  MoveMsgtoNodeTTxDMA  « 


DATE:  3  No\ 

VERSION:  A1 

FUNCTION:  Move: 

to  qi 

INPUTS:  i  =  : 

OUTPUTS:  NONE 

GLOBAL  VARIABLES  USED:  PSTCl 

GLOBAL  VARIABLES  CHANGED:  NONE 


GLOBAL  TABLES  USED: 


GLOBAL  TABLES  CHANGED: 


FILES  READ: 

FILES  WRITTEN: 
MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


3  Nov  83 
A1 

Moves  chars  from  queue  InChar 
to  queue  NodeChar 
i  =  index  into  PST 
NONE 

PSTCharCount 


InChar 

NBT 

PST 

THT 

NBT 

NodeChar 

PST 

NONE 

NONE 

2. 1.2.1  -  BldTransportHeader 

X.7  -  GatherStats 

2.1  -  SrvInputQueue 
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MoveMsgtoNodeTTxDMA  (  i  ) 


/*  index  into  PST  */ 


{ 

char 

int 


♦CharPtr  ; 
j  ; 


BldTransportHeader  (  i  )  ; 

for  (  CharPtr  =  THT,  j  =  0;  j  <  PSTCharCount;  j++  ) 
if  (  j  <  THTSIZE  ) 

NodeChar[NBT[TTxDMA] .Putldx++]  =  * (CharPtr++) ; 

else 

NodeChar[NBT[TTxDMA] .Putldx++]  =  InChar [ PST[ i ]. InGetldx- 

} 

if  (  PSTCharCount  A  0000001  )  /*  if  odd  #  of  characters  */ 
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D.1.9  BldTransportHeader 


/a***#****#***#**#*#*****#*#***#***********##*#***********###**#* 
*  * 


MODULE  NUMBER  /  NAME: 


2. 1.2.1  -  BldTransportHeader 


DATE:  3  Nov  83 

VERSION:  A1 

FUNCTION:  Writes  into  the  15  character 

skeleton  "THT"  to  create  the 
Message  Transport  Layer  Header. 
INPUTS:  i  =  index  into  PST 

OUTPUTS:  NONE 

GLOBAL  VARIABLES  USED:  NBTCharCount 

GLOBAL  VARIABLES  CHANGED:  Las tMsgSeqNbr 


GLOBAL  TABLES  USED: 
GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


PST 

THT 

NONE 

NONE 

NONE 

2.1.2  -  MoveMsgtoNodeTTxDMA 
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•ft*************************************************************/ 


BldTransportHeader  (  i  ) 


/*  PST  index  */ 


strcopy  (  THT.TID, 
THT. Mode 


PST  [i].TID,  3  )  ; 
=  PST  [i].TermMode  ; 


if  ( ++LastMsgSeqNbr  >  MAXMSGSEQNBR  ) 
LastMsgSeqNbr  =  0  ; 


intascii  (  THT.MsgSeqNbr , 
intascii  (  THT.MsgCharCnt , 
strcopy  (  THT.OrgNode, 


LastMsgSeqNbr,  4  ) 
NBTCharCount,  4  ) 
"TTx",  3  )  ; 


return  ; 

} 


D . 1 .10  SrvOutputQueue 


/a***************************** 

* 


****#*###*#**#**#*#*########***«** 


*  MODULE  NUMBER  /  NAME: 

*  DATE: 

*  VERSION: 

*  FUNCTION: 


*  INPUTS: 

*  OUTPUTS: 

*  GLOBAL  VARIABLES  USED: 

*  GLOBAL  VARIABLES  CHANGED: 

*  GLOBAL  TABLES  USED: 

*  GLOBAL  TABLES  CHANGED: 

* 

* 


FILES  READ: 

*  FILES  WRITTEN: 

*  MODULES  CALLED: 

*  CALLING  MODULES: 


»  AUTHOR: 

*  HISTORY: 


2.2  -  SrvOutputQueue 


**»•»**»***«**««*****«**««#**** 


« 
* 

3  Nov  83  * 

A1  * 

Moves  next  screen  character  to  * 
Transmit  Data  Buffer  (XBUF)  if  * 
Transmit  Control  &  Status  * 

Register  (XCSR)  indicates  that  * 
the  buffer  is  ready  for  it.  * 

1  =  index  into  PST  * 

NONE  * 

NONE  * 

NONE  * 

PST  * 

OutChar  * 

PST  * 

NONE  * 

NONE  * 

NONE  * 

2  -  Perf NormalActivities  * 

* 

Capt  Allan  F.  Masty,  GCS-83D  * 

VSN  A1  -  3  November  1983  * 

* 

*•*«•******«***«»**«*****«**««**•/ 


SrvOutputQueue  (  i  ) 

int  i  ;  /*  index  into  the  PST  */ 

{ 

printf  ("\n  ????????  SrvOutputQueue  (  %d  )  " ,  i  )  ; 

if  (  *PST  [i] .TxmStatAddr  &  0200  ) 

{ 

*PST  [ i] .TxmDataAddr  =  OutChar  [PST[ i] .OutGetldx ]  ; 
if  (  ++PST  [i] .OutGetldx  >  PST  [ i] .OutHighldx  ) 

PST  Ci] .OutGetldx  =  PST  [ i ] .OutLowIdx  ; 

} 

return  : 


D . 1 .11  SrvNodeQueue 


/a*************************************************************** 

* 

-  SrvNodeQueue  * 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 

GLOBAL  TABLES  USED: 


GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


2.3 


3  Nov  83 
A1 

Controls  movement  of  chars  from 
NodeChar  to  the  DMA  interface 
or  to  OutChar. 
n  =  index  into  NBT 
NONE 

NBTCharCount 

EndIDX 

NBTCharCount 

NBT 

NodeChar 

PST 

THT 

NBT 

NONE 

NONE 

2.3.1  - 

2.3.2  - 


TTxtoDMAOutput 

DMAtoTTxOutput 


2  -  PerfNormalActivities 
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SrvNodeQueue  (  n  ) 

int  n  ;  /*  index  into  the  NBT*/ 

{ 

int  i  , 

P  ; 

char  *c  ; 

while  (  NBT  [nl.Getldx  !s  NBT  [nl.Putldx  ) 

{ 

i  =  NBROFPORTS  ; 

for  (  p  =  0;  p  <  NBROFPORTS;  p++  ) 

{ 

if  (  strcompare  (PST[p].TID, 

ANodeChar [NBT[n ] .Getldx ] ,  3)  ==  3  ) 

{ 
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i  =  p  ; 

p  =  NBT[n] .Getldx  +  MTHT.MsgCharCnt )  -  &(THT) ; 

c  =  &(  ModeChar  [p]  )  ; 

NBTCharCount  =  asciiint  (  c,  4  )  ; 

Endldx  s  NBT  [  n  ]. Getldx  +  NBTCharCount  ; 

if  (  n  ==  TTxDMA  ) 

TTxtoDMAOutput  ()  ; 

else 

DMAtoTTxOutput  (  i  )  ; 

}  /*  end  ’if'  */ 

>  /*  end  'for'  */ 

if  ( ^ i  ==  NBROFPORTS  ) 

printf  ( "\n  Invalid  TID  r  ")  ; 
while  (  NBT  [  n  ]  .Getldx  !=  NBT  [n].PutIdx  ) 
printf  ( Me ",  NodeChar  [NBT[n]  .Getldx++]  ); 
printf  ("\n\n")  ; 

} 

}  /*  end  'while*  */ 

return  ; 

J 
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D . 1 .12  TTxtoDMAOutput 


/»»*ft****«ft*«*ft«»**«**ft«*«ftft«»**«#»«»»»*»«ft«»ft«****«»»»»«*»#*»*»« 
«  « 


MODULE  NUMBER  /  NAME:  2.3.1  -  TTxtoDMAOutput  * 

* 


* 


DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 

GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


3  Nov  83 
A1 

Controls  movement  of  messages 
from  NodeChar  to  DMA  interface 
NONE 
NONE 

DMABusyFlag 

EndIDX 

DMABusyFlag 

NBT 

NodeChar 

NBT 

NONE 

NONE 

X.7  -  GatherStats 

2.3  -  SrvNodeQueue 
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« 

« 

« 

« 

* 

* 

* 

* 

« 

« 

« 

ft 

* 

« 

* 

« 


***«ft**ftft««ft*«***ft««*«**««ftft*«ftft**«*ftft***ft*«*ft***«*ft**ftftftft***«ft/ 


TTxtoDMAOutput  () 

{ 

if  (  (  DMABusyFlag  ==  0  )  4 4  (  *DMACSR  4  DMAREADY)  ) 

{ 

•DMADBR  =  -( ( Endldx  -  NBT  [TTxDMA] .Getldx )  /  2  )  ; 

•DMACSR  4=  "(DMAOMODE)  ; 

•DMACSR  |=  DMAODIRECTION  ; 

DMABusyFlag  =  3  ;  /*  Output  word  in  progress  */ 

} 

else 

{ 

printf  ( n\nTTxtoDMAOutput  =  DMA  busy  — ")  ; 
printf  ("  DMACSR  =  So",  *DMACSR  )  ; 
printf  C"  DMABusyFlag  =  %dn ,  DMABusyFlag)  ; 

} 


GatherStats  (  4NodeChar  C  NBT[TTxDMA]  .Getldx  3,2)  ; 


while  (  NBT  [TTxDMA] .Getldx  !=  Endldx  ) 

printf  ("Sc",  NodeChar  [  NBT  [TTxDMA] .Getldx++  ]  )  ; 


D . 1 .13  DMAtoTTxOutput 

/a#*##******#*###**#***##*******##****#****#**#*#***********#*** 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 


GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


2.3.2  -  DMAtoTTxOutput 

3  Nov  83 
A1 

Controls  movement  of  messages 

from  NodeChar  to  OutChar 

i  s  index  into  PST 

NONE 

EndIDX 

NONE 

NBT 

NodeChar 

PST 

THT 

NBT 

PST 

NONE 

NONE 

X.7  -  GatherStats 

2.3  -  SrvNodeQueue 

Capt  Allan  F.  Masty,  GCS-83D 
VSN  A1  -  3  November  1983 

*«*»«****««««»***** ****•***««•**/ 


DMAtoTTxOutput  (  i  ) 

int  i  ;  /•  index  into  PST  */ 

{ 

int  p  ; 

GatherStats  (  iNodeChar  [  NBTEDMATTx] .Getldx  ],  2  )  ; 

p  =  NBT  [DMATTx]. Getldx  +  &(THT.Mode)  -  &(THT)  ; 

PST  [i].TermMode  =  NodeChar  [p]  ;  /*  update  LSI  database  */ 

printf  ( "NnDMAtoTTxTransf er  =  ")  ; 

while  (  (  NBT  [DMATTx ] .Getldx  !=  Endldx  )  && 

(  PST  [ i] .OutPutldx  <  PST  [ i] .OutHighldx  )  ) 

{ 

printf  ("?cn,  NodeChar  [  NBT  [DMATTx ] .Getldx ]  )  ; 

OutChar  [PST[ i] .OutPutIdx++]  = 

NodeChar  [NBT[DMATTx] .Getldx++]  ; 


D . 1 .14  TermSystem 

/a**####*##*#******##*#*#****#*#****##****#*#**#*##*##*##*#**#**# 


* 

MODULE  NUMBER  /  NAME:  3  -  TermSystem  * 

* 

DATE:  3  Nov  83  * 

VERSION:  A1  » 

FUNCTION:  Performs  termination  processing  * 

INPUTS:  NONE  * 

OUTPUTS:  NONE  * 

GLOBAL  VARIABLES  USED:  NONE  * 

GLOBAL  VARIABLES  CHANGED:  NONE  * 

GLOBAL  TABLES  USED:  PST  -  * 

GLOBAL  TABLES  CHANGED:  NONE  * 

FILES  READ:  NONE  * 

FILES  WRITTEN:  NONE  * 

MODULES  CALLED:  X.4  -  DispTime  * 

X.6  -  DispElapsedTime  * 

CALLING  MODULES:  0  -  Main  » 

* 

AUTHOR:  Capt  Allan  F.  Masty,  GCS-83D  * 

HISTORY:  VSN  A1  -  3  November  1983  * 


*  # 
**»«*«*«HI<M««*«M*»*MMI«HiM«»****«««HH**H«*»***<««  / 

TermSystem  () 

{ 

int  i  ,  /*  index  into  PST  */ 

•temp  ;  /*  temporary  pointer  •/ 

for  (  i  =  0;  i  <  NBROFPORTS ;  i++  ) 

{  /*  restore  old  interrupt  settings  */ 

temp  s  PST  [  i  ] .IntVectAddr  ; 

*(  temp  )  s  PST  [  i  ] .StorlntVect  ; 

*(temp+1 )  =  PST  [  i  ].StorPSW  ; 


printf  ( ”\n\n++++++++  FEP  aborted  at  ")  ; 
DispTime  ()  ; 

printf  ("-  -  -  ->  elapsed  time  =  ")  ; 

DispElapsedTime  ()  ; 

fclose  (  fp  )  ; 

return  ; 

} 


D.1 .15  SOCInterruptServiceRoutine 

/a#####*##*######*###***##*##*#####*##*##****##*##****#****#*#** 


* 


MODULE  NUMBER  /  NAME:  1.2.1  -  SOCInterruptServiceRoutine  * 

* 


DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 


3  Nov  83 
A1 

Controls  movement  of  characters 
from  Receiver  Data  Buffer  (RBUF) 
to  queue  InChar. 

NONE 

NONE 

NONE 

AbortFlag 

PST 

InChar 

PST 

NONE 

NONE 

NONE 

1.2  -  Initlnterrupts  (activation) 


* 


* 


AUTHOR: 

HISTORY: 


Capt  Allan  F.  Masty,  GCS-83D 
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*»***********«««**•***«**««««**«*««****«•*•«**«*****•*«*•«**«**/ 


SOCInterruptServiceRoutine  () 

{ 

entint  ()  ;  /*  save  registers  */ 

InChar  [PSTCSOC] .InPutldx ]  =  *PST[SOC] .RcvDataAddr  ; 
*PST[SOC] .TxmDataAddr  =  »PST[SOC] .RcvDataAddr  ; 

if  (  InChar  [  PST  [SOC] .InPutldx  ]  ==  CR  ) 

*PST  CSOC] .TxmDataAddr  =  LF  ; 

switch  (  InChar  C  PST  [SOC] .InPutldx  ]  ) 

{ 

case  CTRLC  : 

{ 

AbortFlag  =  YES  ; 
break  ; 

} 

case  DEL  : 

{ 

if  (  PST  [SOC]. InPutldx  >  PST  [SOC] .InGetldx  ) 

{ 


*  * 


— PST  [SOC] .XnPutldx  ; 

*PST  [SOC] .TxmDataAddr  =  BACKSPACE  ; 

while  ((*PST[SOC] .TxmStatAddr  &  0200)  ==  0); 

*PST  [SOC] .TxmDataAddr  =  SPACE  ; 

while  (( *PST[S0C] .TxmStatAddr  &  0200)  ==  0); 

*PST  [SOC] .TxmDataAddr  =  BACKSPACE  : 

} 

break  ; 

} 

default  : 

{ 

if  ( ++PST  [SOC] .InPutldx  =  =  PST  [SOC] .InHighldx  ) 
—  PST  [SOC]  .InPutldx  ; 
break  ; 

} 


retint  ()  ;  /»  restore  registers  */ 

return  ; 


D— 3 1 


»>■  -  *  ^  »  A  A  • VA  ■ 


*  .  1 


D . 1  .16  T1 InterruptServiceRoutine 


/***«*«*****«»ft**ft***«**««««*«*****tf***ft**««*****«tt*«************ 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 


INPUTS:  NONE 
OUTPUTS:  NONE 
GLOBAL  VARIABLES  USED:  NONE 
GLOBAL  VARIABLES  CHANGED:  NONE 


GLOBAL  TABLES  USED: 
GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


1.2.2  -  T1 InterruptServiceRoutine  * 

* 

3  Nov  83  * 

A1  * 

Controls  movement  of  characters  * 

from  Receiver  Data  Buffer  (RBUF)  * 

to  queue  InChar.  * 

NONE  « 

NONE  « 

NONE  * 


PST 

InChar 

PST 

NONE 

NONE 

NONE 

1.2  -  Initlnterrupts  (activation) 

Capt  Allan  F.  Masty,  GCS-83D 
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*«*»•**•««**««««««•«»******«««•**«««*«***«•««*«**«*«*•**»»*•*•««/ 

T1 InterruptServiceRoutine  () 


entint  ()  ; 


/*  save  registers  */ 


InChar  [PST[T1 ]  .InPutldx ]  =  »PST[T1 3 . RcvDataAddr  ; 
*PST[T1 ] .TxmDataAddr  =  *PST[T1 ]. RcvDataAddr  ; 

if  (  InChar  [  PST  [T1 ] .InPutldx  ]  ==  CR  ) 

*PST  [T1 ] .TxmDataAddr  =  LF  ; 

if  (  InChar  [  PST  [T1 ] .InPutldx  ]  ==  DEL  ) 

{ 

if  (  PST  CT1 ]  .InPutldx  >  PST  [T1 3 .InGetldx  ) 

{ 

—  PST  CT1  ]  .InPutldx  ; 

*PST  CT1 ] .TxmDataAddr  =  BACKSPACE  ; 
while  ( ( *PST[T1 3 .TxmStatAddr  &  0200)  ==  0); 
*PST  [T1 3 .TxmDataAddr  =  SPACE  ; 
while  ((»PST[T1 3 .TxmStatAddr  4  0200)  ==  0); 
*PST  [T1 3 .TxmDataAddr  =  BACKSPACE  ; 

} 

} 


else 

if  (++PST  [T1 3 . InPutldx  r=  PST  [T1 3 . InHighldx  ) 
— PST  [T1 3 .InPutldx  ; 

retint  ()  ;  /*  restore  registers  */ 

return  ; 

} 


D . 1 .17  T2InterruptServiceRoutine 


/ft*************************************************************** 
*  * 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


1.2.3  -  T2InterruptServiceRoutine  * 

« 

3  Nov  83  * 

A1  * 

Controls  movement  of  characters  * 

from  Receiver  Data  Buffer  (RBUF)  * 
to  queue  InChar.  * 

NONE  * 

NONE  * 

NONE  » 

NONE  * 

PST  * 

InChar  * 

PST  * 

NONE  * 

NONE  * 

NONE  * 

1.2  -  Initlnterrupts  (activation)  * 

* 

Capt  Allan  F.  Masty,  GCS-83D  * 

VSN  A1  -  3  November  1983  * 

« 

******** *•*****••*****************/ 


T2InterruptServiceRoutine  () 

{ 

entint  ()  ;  /•  save  registers  •/ 

InChar  [PST[T2]  .InPutldx ]  =  *PST[T2] .RcvDataAddr  ; 
*PST[T2] .TxmDataAddr  =  «PST[T2] .RcvDataAddr  ; 

if  (  InChar  [  PST  [T2] .InPutldx  ]  =r  CR  ) 

•PST  [T2] .TxmDataAddr  =  LF  ; 

if  (  InChar  [  PST  [T2] .InPutldx  ]  ==  DEL  ) 

{ 

if  (  PST  CT2 3 .InPutldx  >  PST  [T2] .InGetldx  ) 

{ 

—  PST  [T2]  .InPutldx  ; 

•PST  [T2] .TxmDataAddr  =  BACKSPACE  ; 

while  ( ( *PST[T2 ] .TxraSta tAddr  &  0200)  ==  0); 

•PST  [T2] .TxmDataAddr  =  SPACE  ; 

while  ( ( *PST[T2] .TxmSta tAddr  &  0200)  ==  0); 

•PST  [T2] .TxmDataAddr  =  BACKSPACE  ; 

} 

} 


D-34 


D . 1 .18  T3InterruptServiceRoutine 

/**********«******«******************************«««*******#«**** 

# 

MODULE  NUMBER  /  NAME:  1.2.4  -  T3InterruptServ iceRoutine  * 

* 

DATE:  3  Nov  83  * 

VERSION:  A1  * 

FUNCTION:  Controls  movement  of  characters  * 

from  Receiver  Data  Buffer  (RBUF)  * 

to  queue  InChar.  * 

INPUTS:  NONE  * 


*  OUTPUTS:  NONE  * 

*  GLOBAL  VARIABLES  USED:  NONE  * 

*  GLOBAL  VARIABLES  CHANGED:  NONE  * 

*  GLOBAL  TABLES  USED:  PST  * 

*  GLOBAL  TABLES  CHANGED:  InChar  * 

*  PST  * 

*  FILES  READ:  NONE  * 

*  FILES  WRITTEN:  NONE  * 

*  MODULES  CALLED:  NONE  * 

*  CALLING  MODULES:  1.2  -  Ini tlnterrupts  (activation)  * 

*  « 

*  AUTHOR:  Capt  Allan  F.  Masty,  GCS-83D  * 

*  HISTORY:  VSN  A1  -  3  November  1983  * 

*  « 


*•*•**••****•*«**•••***«****•**«*«*•«•*««******»*****«•**«******/ 

T3InterruptServiceRoutine  () 

{ 

entint  ()  ;  /*  save  registers  */ 

InChar  [PST[T3] .InPutldx]  =  *PST[T3 ] . RcvDataAddr  ; 

*PST[T33 .TxmDataAddr  =  *PST[T3 ]. RcvDataAddr  ; 


if  (  InChar  [  PST  [T3 3  .InPutldx  ]  ==  CR  ) 

*PST  [T31 .TxmDataAddr  =  LF  ; 

if  (  InChar  C  PST  [T3 3  .InPutldx  ]  ==  DEL  ) 

{ 

if  (  PST  [T3 3 .InPutldx  >  PST  [T3 3 . InGetldx  ) 

{ 

—  PST  CT3 3  .InPutldx  ; 

*PST  CT3 3 .TxmDataAddr  =  BACKSPACE  ; 

while  ((*PST[T31 .TxmStatAddr  &  0200)  =r  0); 

*PST  [T3 3 .TxmDataAddr  =  SPACE  ; 

while  ( ( *PST[T3 3 .TxmStatAddr  &  0200)  ==  0); 

*PST  [T3 3 .TxmDataAddr  =  BACKSPACE  : 


else 

if  (  ++PST  [T3 ]  .InPutldx  >  PST  [T3 ] . InHighldx  ) 
—  PST  [T3 ]  .InPutldx  ; 

retint  ()  ;  /*  restore  registers  */ 

return  ; 

} 


D . 1 .19  T4InterruptServ iceRoutine 


/***«*«**tt***««ft**ft**tt««***********ft*******X«**«*X*******#*fi****« 
*  * 


*  MODULE  NUMBER  /  NAME: 

* 

*  DATE: 

*  VERSION: 

*  FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


1.2.5  -  T4InterruptServ iceRoutine  * 

* 

3  Nov  83  * 

A1  « 

Controls  movement  of  characters  * 

from  Receiver  Data  Buffer  (RBUF)  * 

to  queue  InChar.  * 


NONE  * 

NONE  * 

NONE  * 

NONE  * 

PST  * 

InChar  * 

PST  * 

NONE  * 

NONE  * 

NONE  * 

1.2  -  Initlnterrupts  (activation)  * 

* 

Capt  Allan  F.  Masty,  GCS-83D  * 

VSN  A1  -  3  November  1983  * 

* 


*************************************************************** / 


T4InterruptServiceRoutine  () 

{ 

entint  ()  ;  /*  save  registers  */ 

InChar  [PST[T4]  .InPutldx ]  =  *PST[T4] .RcvDataAddr  ; 
*PST[T4] .TxmDataAddr  =  *PST[T4] .RcvDataAddr  ; 

if  (  InChar  [  PST  [T4] .InPutldx  ]  ==  CR  ) 

*PST  [T4] .TxmDataAddr  =  LF  ; 

if  (  InChar  [  PST  [T4 3  .InPut Idx  ]  ==  DEL  ) 

{ 

if  (  PST  [T4] .InPutldx  >  PST  [T4]  .InGetldx  ) 

{ 

—  PST  [T43  .InPutldx  ; 

*PST  [T4] .TxmDataAddr  =  BACKSPACE  ; 
while  ( ( *  PST  C  T4  3 .TxmStatAddr  &  0200)  ==  0); 
*PST  [T4] .TxmDataAddr  =  SPACE  ; 
while  ((*PST[T4] .TxmStatAddr  &  0200)  ==  0); 
*PST  [T4] .TxmDataAddr  =  BACKSPACE  ; 

} 


else 

if  (  ++PST  [T4 ] . InPutldx  >  PST  [T4 ] . InHighldx  ) 
—PST  [T4]  .InPutldx  ; 

retint  ()  ;  /*  restore  registers  */ 

return  ; 


D.1.20  T5InterruptServiceRoutine 

/a***#**#***#*********#*******#****#*#*##*#****#*#**###*##****##* 
«  * 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 


1.2.6  -  T5InterruptServiceRoutine  * 


3  Nov  83 

A1 

Controls  movement  of  characters 
from  Receiver  Data  Buffer  (RBUF) 
to  queue  InChar. 

NONE 

NONE 

NONE 


GLOBAL  VARIABLES  CHANGED:  NONE 


GLOBAL  TABLES  USED: 
GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


PST 

InChar 

PST 

NONE 

NONE 

NONE 

1.2  -  Initlnterrupts  (activation) 

Capt  Allan  F.  Masty,  GCS-83D 
VSN  A1  -  3  November  1983 


»***«*•**»*««******•**»»«*«•*** *«**«*«« *•«***•****« * *«*«*«* *«#«*/ 

T5InterruptServiceRoutine  () 


entint  ()  ; 


/*  save  registers  */ 


InChar  [PSTCT5] .InPutldx]  =  «PST[T5] .RcvDataAddr  ; 
*PST[T5] .TxmDataAddr  =  *PST[T5] .RcvDataAddr  ; 

if  (  InChar  C  PST  [T5] .InPutldx  ]  ==  CR  ) 

*PST  [ T5 ] .TxmDataAddr  =  LF  ; 

if  (  InChar  [  PST  [T53 .InPutldx  ]  ==  DEL  ) 

{ 

if  (  PST  [T53. InPutldx  >  PST  [T5 ] .InGetldx  ) 

{ 

—  PST  CT5]  .InPutldx  ; 

*PST  [T53 .TxmDataAddr  =  BACKSPACE  ; 
while  ( ( *PST[T5 ] .TxmStatAddr  &  0200)  ==  0); 
*PST  CT5] .TxmDataAddr  =  SPACE  ; 
while  ((*PST[T5] .TxmStatAddr  &  0200)  ==  0); 
*PST  [T53 .TxmDataAddr  =  BACKSPACE  ; 

} 

} 


else 

if  (  ++PST  [T5 3 . InPutldx  >  PST  [T5 3 . InHighldx  ) 
—  PST  [T53  .InPutldx  ; 

retint  ()  ;  /*  restore  registers  */ 

return  ; 


D . 1 .21  T6InterruptServ iceRoutine 

/*******#**#******###****#*#*»**###»#*#**#*###**###***#**##*#*#** 
*  « 

*  MODULE  NUMBER  /  NAME:  1.2.7  -  T6InterruptServ iceRoutine  * 

*  * 

*  DATE:  3  Nov  83  * 

*  VERSION:  A1  * 

*  FUNCTION:  Controls  movement  of  characters  * 

*  from  Receiver  Data  Buffer  (RBUF)  * 

*  to  queue  InChar.  * 

*  INPUTS:  NONE  « 

*  OUTPUTS:  NONE  * 

*  GLOBAL  VARIABLES  USED:  NONE  * 

*  GLOBAL  VARIABLES  CHANGED:  NONE  * 

*  GLOBAL  TABLES  USED:  PST  * 


GLOBAL  TABLES  CHANGED:  InChar  * 

PST  * 

FILES  READ:  NONE  * 

FILES  WRITTEN:  NONE  * 

MODULES  CALLED:  NONE  * 

CALLING  MODULES:  1 .2  -  Initlnterrupts  (activation)  * 

* 

AUTHOR:  Capt  Allan  F.  Masty,  GCS-83D  * 

HISTORY:  VSN  A1  -  3  November  1983  * 

* 


ft***************************************************************/ 

T6InterruptServiceRoutine  () 

{ 

entint  ()  ;  /*  save  registers  */ 

InChar  [PST[T6] .InPutldx ]  =  *PST[T6 ] . RcvDataAddr  ; 

*PST[T6] .TxmDataAddr  =  *PST[T6 ] .RcvDataAddr  ; 

if  (  InChar  [  PST  [T6 ]. InPut Idx  ]  ==  CR  ) 

*PST  [T6] .TxmDataAddr  =  LF  ; 

if  (  InChar  [  PST  [T6] .InPutldx  ]  ==  DEL  ) 

if  (  PST  [T6] .InPutldx  >  PST  [T6] .InGetldx  ) 

{ 

—  PST  [T6]  .InPutldx  ; 

*PST  [T6] .TxmDataAddr  =  BACKSPACE  ; 
while  ((*PST[T63 .TxmStatAddr  &  0200)  ==  0); 

*PST  [T63 .TxmDataAddr  =  SPACE  ; 

while  ( ( *PSTCT63 .TxmStatAddr  &  0200)  =r  0); 

*PST  [T6] .TxmDataAddr  =  BACKSPACE  ; 


else 


if  (  ++PST  [T6] .InPutldx  >  PST  [T6] .InHighldx  ) 
—  PST  [T6]  .InPutldx  ; 

retint  ()  ;  /*  restore  registers  */ 

return  ; 

} 


D.1.22  T7InterruptServiceRoutine 

/ft*************************************************************** 
*  * 

*  MODULE  NUMBER  /  NAME:  1.2.8  -  T7InterruptServ iceRoutine  * 


DATE:  3  Nov  83 

VERSION:  A1  * 

FUNCTION:  Controls  movement  of  characters  * 

from  Receiver  Data  Buffer  (RBUF)  * 
to  queue  InChar.  * 

INPUTS:  NONE  * 

OUTPUTS:  NONE  « 

GLOBAL  VARIABLES  USED:  NONE  « 

GLOBAL  VARIABLES  CHANGED:  NONE  « 

GLOBAL  TABLES  USED:  PST  * 

GLOBAL  TABLES  CHANGED:  InChar  * 

PST  * 

FILES  READ:  NONE  * 

FILES  WRITTEN:  NONE  * 

MODULES  CALLED:  NONE  « 

CALLING  MODULES:  1.2  -  Initlnterrupts  (activation)  * 

* 

AUTHOR:  Capt  Allan  F.  Masty,  GCS-83D  * 

HISTORY:  VSN  A1  -  3  November  1983  * 


«  * 
*•*•*•«***««**«*•**«*•*«»**«»**•••*••*«•****«•***•***********«**  f 

T7InterruptServ iceRoutine  () 

{ 

entint  ()  ;  /*  save  registers  */ 

InChar  [PST[T7] .InPutldx 3  =  *PST[T7) . RcvDataAddr  ; 

*PST[T7] .TxmDataAddr  =  *PST[T7] .RcvDataAddr  ; 

if  (  InChar  [  PST  [T7l  .InPutldx  ]  ==  CR  ) 

*PST  [T71 .TxmDataAddr  =  LF  ; 

if  (  InChar  [  PST  [T7] .InPutldx  ]  ==  DEL  ) 

{ 

if  (  PST  [T73 .InPutldx  >  PST  [T7 3 .InGetldx  ) 

{ 

—PST  CT7 3  .InPutldx  ; 

•PST  [T73 .TxmDataAddr  =  BACKSPACE  ; 
while  ((»PST[T73 .TxmSta tAddr  &  0200)  =r  0); 

•  PST  [T7 3 .TxmDataAddr  =  SPACE  ; 

while  ((*PST[T7l .TxmStatAddr  &  0200)  ==  0); 

•  PST  CT7 3 .TxmDataAddr  =  BACKSPACE  ; 

} 


*  * 


if  (  ++PST  [ T7 3 .InPutldx  >  PST  [T7 ] . InHighldx  ) 
—  PST  [T7]  .InPutldx  ; 

retint  ()  ;  /*  restore  registers  */ 

return  ; 


D.1  .23  DMAInterruptServiceRoutine 


/##*#*#*#«**#******#*»*»***#**#»************##**HHHHHHHHHHHf****** 


MODULE  NUMBER  /  NAME: 


1.2.9  -  DMAInterruptServiceRoutin  * 

* 


DATE:  3  Nov  83 

VERSION:  A1 

FUNCTION:  Controls  movement  of  characters 

from  the  DMA  interface  to  NodeChar 
INPUTS:  NONE 

OUTPUTS:  NONE 

GLOBAL  VARIABLES  USED:  DMABusyFlag 

DMAwc 

GLOBAL  VARIABLES  CHANGED:  DMABusyFlag 

DMAwc 

GLOBAL  TABLES  USED:  NBT 

NodeChar 

PST 

GLOBAL  TABLES  CHANGED:  NBT 

PST 

FILES  READ:  NONE 

FILES  WRITTEN:  NONE 

MODULES  CALLED:  1.2. 9.1  -  SetUpForlnputDMA 

CALLING  MODULES:  1.2  -  Initlnterrupts  (activation) 


GLOBAL  TABLES  USED: 


GLOBAL  TABLES  CHANGED: 

FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 


AUTHOR: 

HISTORY: 


Capt  Allan  F.  Masty,  GCS-83D 
VSN  A1  -  3  November  1983 


a**************************************************************/ 


DMAInterruptServiceRoutine  () 


{ 

entint  ()  ;  /*  save  registers  */ 

printf  ("\n  ...  DMACSR  =  Jo  \n",  *DMACSR  )  ; 

if  (  *DMACSR  4  DMANEX  )  /*  if  NEX  memory  accessed  */ 

printf  ("\n  .  .  .  .  NEX  at  Jo",  *DMABAR  )  ; 

else 

{ 

if  (  *DMACSR  4  DMAIREQUEST  )  /*  host  input  request  */ 

SetUpForlnputDMA  ()  ; 

else 

{ 

printf  ("\n  ....  Output  Transfer  Complete\n\n" )  ; 
switch  DMABusyFlag 
{ 

case  1  :  /*  Input  word  expected  */ 

{ 


printf  (n\n  DMABusyFlag  =  £d\n" , DMABusyFlag ) ; 

DM Awe  =  »DMADBR  ; 

if  ( ( NBT[DMATTx] .  Putldx +( DMAwc *2) ) 

<=  NBTCDMATTx] .Highldx) 

{ 

++DMABusyFlag  ;  /»  block  input  expected  */ 
•DMABAR  =  &( Node Char [NBTCDMATTx] .Putldx]) ; 
•DMAWCR  =  -DMAwc  ; 

•DMACSR  ! =  DMAODIRECTION  ; 

•DMACSR  &=  “DMAOMODE  ; 

•DMACSR  |=  DM AGO  ; 

} 

printf  (”\n  +=+=  DMAwc  =  *d  ,  Putldx  =  * d  \ 
DMAwc,  NBTCDMATTx] .Putldx  ); 

break  ; 

} 


case  2  :  /•  Input  block  expected  */ 

{ 

printf  ("\n  DMABusyFlag  r  %d\n” , DMABusyFlag) ; 
break  ; 

} 


case  3  :  /•  Output  word  in  progress  */ 

{ 

printf  ("\n  DMABusyFlag  =  %d\n" , DMABusyFlag) ; 
break  ; 

} 


case  4  :  /*  Output  block  in  progress  */ 

{ 

printf  ("\n  DMABusyFlag  =  td\n" , DMABusyFlag) ; 
break  ; 

} 


default  : 

{ 

printf  ("\n  DMABusyFlag  =  %d\n" , DMABusyFlag) ; 
break  ; 

} 


/•  end  of  ’switch1  processing  */ 


retint  ()  ; 


/•  restore  registers  */ 


return  ; 
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'  v  v  V  V  V  •*. 


D.1.24  SetUpFor InputDMA 


/a#**######***##**#*##**##**#*****##*###**##*****#***###****#**## 
*  * 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


1.2. 9.1  -  SetUpFor Input DM A  * 

* 

3  Nov  83  * 

A1  * 

Programs  the  DMA  interface  to  * 

receive  a  transfer  from  Host.  * 

NONE  * 

NONE  * 

NONE  * 

DMABusyFlag  * 

InChar  * 

PST  * 

PST  * 

NONE  * 

NONE  * 

NONE  * 

1.2.9  -  DMAInterruptServiceRoutine* 

* 

Capt  Allan  F.  Masty,  GCS-83D  * 

VSN  A1  -  3  November  1983  * 


••*****•••**•**••**««****»««**•«*•«**•*»*«••«»****»•*•••***«***/ 


G  SetUpFor InputDMA  () 

{ 

printf  ("\n  .  .  DMA  Input  Interrupt  Request")  ; 

DMABusyFlag  =  1  ;  /*  Input  word  expected  */ 

•DMABAR  =  &(  InChar  [PST  [DMA] .InPutIdx++]  )  ; 

if  (  *DMACSR  &  DMAIMODE  )  /•  if  request  for  'word'  mode  */ 

{ 

•DMACSR  1=  DMAOMODE  ;  /*  set  output  'word*  mode  */ 

•DMAWCR  =  -1  ;  /*  set  Word  Count  register  */ 

} 

else  /•  request  is  for  'block*  transfer  •/ 

•DMACSR  &  =  ~(  DMAOMODE  );  /•  set  output  'block'  mode  */ 

•DMAWCR  =  -(  DM Awe  )  ;  /*  set  Word  Count  register  */ 

DMABusyFlag++  ;  /•  Input  block  expected  */ 

} 

printf  ("\n  ...  DMACSR  =  %o  \n",  *DMACSR  )  ; 

return  ; 

} 
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D.2  LFEPHI.C  Program  modules 


/a##*#*#**#*####**##**### **************************************** 
*  * 

*  TITLE:  LSI  FEP  Extended  Memory  ’ C*  Program  * 

*  FILENAME:  LFEPHI.C  * 

»  • 


DATE: 

3  Nov  83 

* 

VERSION: 

A1 

* 

OWNER: 

Capt 

Allan  F.  Masty 

• 

COMPUTER  SYSTEM: 

LSI- 

11/23 

* 

OPERATING  SYSTEM: 

RT11XM 

* 

LANGUAGE: 

Telecon 

*C* 

* 

* 

CONTENTS: 

X.1 

DispPST 

* 

X.2 

- 

DispNBT 

* 

X.3 

- 

GetCurrentTime 

* 

x.u 

- 

DispTime 

* 

X .  5 

- 

CalcElapsedTime 

* 

X.6 

- 

DispElapsedTime 

* 

X  .7 

- 

GatherStats 

* 

* 


FUNCTION:  Provides  an  extended  memory  resident  * 

collection  of  service  subroutines  for  * 

use  by  the  low  memory  LFEPLO.C  program  * 

* 

*#*##»**«**#*»«*##*#*#**#*##»*«**#*«**»*#«**##*#»*##***********/ 


/* 


GLOBALS 


»/ 


#include  "lfepio.h"  /*  Standard  10  routines  */ 

extern  int  fopen  ()  ; 

/*  .  .  .  gtime  ()  subr  call  data  structure  support  .  .  .  */ 

struct  timerec 

{ 


int 

wl  ; 

/* 

high 

order 

byte  = 

minutes, 

low 

order 

byte  = 

hours 

»/ 

int 

w2  ; 

/« 

high 

order 

byte  = 

tics , 

low 

order 

byte  = 

seconds 

*/ 

char  tim  [11]  ; 
int 

StartHr  =  -1  , 


*.  N  V 


extern  int 


StartMin  =  -1  , 
StartSec  =  -1  , 
StartTic  =  -1  , 

hours  , 
minutes  , 
seconds  , 
ticks  ; 


/*  •  •  Port  Status  (  PS  )  Table  defines  &  declarations  .  .  */ 


^define  NBROFPORTS 


/*  NBROFTERMINALS  +SOC  +DMA  */ 


struct  PortStatusRecord 

{ 

char  TID  [4]  ; 
char  TermMode  ; 

int  InLowIdx  ; 
int  InPutldx  ; 
int  InGetldx  ; 
int  InHighldx  ; 

int  OutLowIdx  ; 
int  OutPutldx  ; 
int  OutGetldx  ; 
int  OutHighldx  ; 

int  *RcvStatAddr  ; 
int  *RcvDataAddr  ; 
int  *TxmStatAddr  ; 
int  *TxmDataAddr  ; 


/*  VT-100  Terminal  ID  */ 

/*  line  or  character  mode  */ 

/*  Input  buffer  pointers  */ 


/*  Output  buffer  pointers  */ 


/*  receive  port  status  addr  */ 
/*  receive  port  data  addr  */ 
/*  transmit  port  status  addr*/ 
/*  transmit  port  data  addr  */ 


•intVectAddr  ;  /*  receive  port  int.  addr  */ 

IntRoutineAddr  ;  /*  Interrupt  service  routine*/ 

StorlntVect  ; 

StorPSW  : 


^define  PSRSIZE  sizeof  (  PortStatusRecord  ) 


/* . raise  defines  for  Node  Buffer  table 


#def ine 


NBROFBUFFERS  2  /*  Nmbr  of  Node  buffers  */ 
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Node  Buffer  Table  declaration 


struct  NodeBuf ferRecord 

{ 


char 

OrgNode  [4]  ; 

int 

Lowldx  ; 

int 

Putldx  ; 

int 

Getldx  ; 

int 

Highldx  ; 

>  ; 

^define  NBRSIZE  sizeof  (  NodeBuf ferRecord  ) 


/«  ....  Message  Transport  Layer  Header  .  .  . 


struct  MsgTransportLayerHeader 

{ 

char  TID  [3]  ; 

char  Mode  ; 

char  MsgSeqNbr  [4]  ; 
char  MsgCharCnt  [4]  ; 

char  OrgNode  [3]  ; 

}  ; 

^define  THTSIZE  sizeof  (  MsgTransportLayerHeader  ) 


/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
X  X 


X 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


X.1  -  DispPST  * 

x 

3  Nov  83  * 

A1  * 

Displays  (upon  the  SOC  terminal  * 

screen)  certain  PST  values.  * 

P  =  pointer  to  PST  * 

NONE  « 

NONE  * 

NONE  * 

PST  * 

NONE  * 

NONE  * 

NONE  * 

NONE  * 

2.1.1  -  EvalSOCInput  * 

x 

Capt  Allan  F.  Masty,  GCS-83D  * 

VSN  A1  -  3  November  1983  * 

x 


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/ 


DispPST  (  P  ) 

struct  PortStatusDataRecord  *P  ; 


int  i  ;  /*  loop  control  variable  */ 

printf  ("\n  i  TID  M  I.LOW  I.PUT  I .GET  I. HIGH")  ; 
printf  ("  0. LOW  O.PUT  O.GET  0. HIGH\n\n" )  ; 

for  (  i  =  0;  i  <  NBROFPORTS  ;  i++  ) 

{ 

printf  ("  Sd",  i  )  ; 
printf  ("  Ss",  P->  TID  )  ; 
printf  ("  Sc",  P->  TerraMode  )  ; 

if  (  P->  InLowIdx  <  1000  ) 
printf  ("  ")  ; 
if  (  P->  InLowIdx  <  100  ) 

printf  ("  ")  ; 
if  (  P->  InLowIdx  <  10  ) 

printf  ("  ")  ; 

printf  ("  Sd",  P->  InLowIdx  )  ; 


v 


if  (  P->  InPutldx  <  1000  ) 
printf  ("  n)  ; 
if  (  P->  InPutldx  <  100  ) 

printf  ("  " )  ; 
if  (  P->  InPutldx  <  10  ) 

printf  ( "  " )  ; 

printf  ("  %d",  P->  InPutldx  ) 

if  (  P->  InGetldx  <  1000  ) 
printf  ("  n)  ; 
if  (  P->  InGetldx  <  100  ) 

printf  ("  ")  ; 
if  (  P->  InGetldx  <  10  ) 

printf  ("  ")  ; 

printf  ("  ?d",  P->  InGetldx  ) 

if  (  P->  InHighldx  <  1000  ) 
printf  (»  ")  ; 
if  (  P->  InHighldx  <  100  ) 

printf  ("  ")  ; 
if  (  P->  InHighldx  <  10  ) 

printf  (»  ")  ; 

printf  ("  %d",  P->  Ini 


P->  InHighldx  ) 


if  (  P->  OutLowIdx  <  1000  ) 
printf  <"  ")  ; 
if  (  P->  OutLowIdx  <  100  ) 

printf  ("  »)  ; 
if  (  P->  OutLowIdx  <  10  ) 

printf  (»  »)  ; 

printf  ("  %d",  P->  OutLowIdx  ) 

if  (  P->  OutPutldx  <  1000  ) 
printf  ("  ")  ; 
if  (  P->  OutPutldx  <  100  ) 

printf  ("  ")  ; 
if  (  P->  OutPutldx  <  10  ) 

printf  (»  ")  ; 

printf  («  %dn ,  P->  OutPutldx  )  ; 

if  (  P->  OutGetldx  <  1000  ) 
printf  (n  ")  ; 
if  (  P->  OutGetldx  <  100  ) 

printf  ("  ")  ; 
if  (  P->  OutGetldx  <  10  ) 

printf  ("  ”)  ; 

printf  ("  %d",  P->  OutGetldx  )  ; 

if  (  P->  OutHighldx  <  1000  ) 
printf  ("  ")  ; 

if  (  P->  OutHighldx  <  100  ) 


printf  ("  «)  ; 

if  (  P->  OutHighldx  <  10  ) 

printf  ("  ")  ; 

printf  ("  %d” ,  P->  OutHighldx  ) 

printf  ("\n")  ; 

P  +=  PSRSIZE  ; 

} 


return 


D.2.2  DispNBT 


/a#*****###*#*#***#*##*#*###**##########****##***#****####*##**** 

* 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


X .  2  -  DispNBT  * 

3  Nov  83  * 

A1  * 

Displays  (upon  the  SOC  terminal  * 

screen)  certain  NBT  values. 

P  =  pointer  to  NBT 
NONE 
NONE 
NONE 
NBT 
NONE 
NONE 
NONE 
NONE 

2.1.1  -  EvalSOCInput 


« 
* 
* 
* 
* 
* 
* 
* 
* 
» 
« 
* 
* 
* 
* 

ft**************************************************************/ 

DispNBT  (  P  ) 

*P  ; 

/*  loop  control  variable  */ 
get  high  \n\nM  )  ; 


Capt  Allan  F.  Masty,  GCS-83D 
VSN  A1  -  3  November  1983 


struct 

{ 

int 


NodeBuf fer Record 

n  ; 

printf  ("\n  i  low  put 


for  (  n  =  0;  n  <  (  NBROFBUFFERS  );  n++  ) 

{ 

printf  ("  Xd"f  n  )  ; 


if 

(  P->  Lowldx 

< 

10000 

) 

printf  ("  ") 

• 

9 

if 

(  P->  Lowldx 

< 

1000 

) 

printf  ("  ") 

• 

9 

if 

(  P->  Lowldx 

< 

100 

) 

printf  (n  ") 

• 

9 

if 

(  P->  Lowldx 

< 

10 

) 

printf  ("  ") 

m 

9 

printf  (»  *d», 

P-> 

Lowldx 

if 

(  P->  Putldx 

< 

10000 

) 

printf  ("  ") 

• 

9 

if 

(  P->  Putldx 

< 

1000 

) 

printf  ( "  ") 


if 

(  P->  Put Idx 

¥ 

< 

100  ) 

printf  ("  ") 

• 

9 

if 

(  P->  Put Idx 

< 

10  ) 

printf  ("  '») 

• 

9 

printf  ("  %d", 

P-> 

Putldx  ) 

if 

(  P->  Getldx 

< 

10000  ) 

printf  (”  ") 

• 

9 

if 

(  P->  Getldx 

< 

1000  ) 

printf  (w  " ) 

• 

9 

if 

(  P->  Getldx 

< 

100  ) 

printf  (n  n) 

• 

9 

if 

(  P->  Getldx 

< 

10  ) 

printf  ("  ") 

• 

9 

printf  ("  ?d", 

P-> 

Getldx  ) 

if 

(  P->  Highldx 

< 

10000  ) 

printf  (n  ") 

• 

9 

if 

(  P->  Highldx 

< 

1000  ) 

printf  ("  ") 

• 

9 

if 

(  P->  Highldx 

< 

100  ) 

printf  (n  ”) 

• 

9 

if 

(  P->  Highldx 

< 

10  ) 

printf  ("  ” )  ; 

printf  ("  *d\n",  P->  Highldx  ) 

P  +=  NBRSIZE  ; 

} 

return  ; 

} 


i 
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D.2.3  GetCurrentTime 

/**»»»*««#*»*«*«***»****»«»#»***«*«#»»»*»*#*«««*«»****«»«*«***«*» 


MODULE  NUMBER  /  NAME: 

DATE: 

VERSION: 

FUNCTION: 


INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 
GLOBAL  VARIABLES  CHANGED: 


GLOBAL  TABLES  USED: 
GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR: 

HISTORY: 


GetCurrentTime  () 


* 

X.3  -  GetCurrentTime  * 

3  Nov  83  * 

A1  « 

Evokes  Macro-11  coded  function  * 
"gtime"  (located  in  library  * 
LFMLLO. MAC )  to  read  system  time  * 
NONE  * 

NONE  * 

hours,  minutes,  seconds,  ticks  * 
hours,  minutes,  seconds,  ticks,  * 
StartHr,  StartMin,  StartSec,  * 
StartTic.  * 

time  * 

time,  tim  * 

NONE  * 

NONE  * 

NONE  * 

X.4  -  DispTime  * 

* 

Capt  Allan  F.  Masty,  GCS-83D  * 

VSN  A1  -  3  November  1983  * 

* 

*««**«#****•*««««**«*««»»«*»**» « / 


{ 

int  k  ; 

gtime  (  time  )  ; 

hours  =  time.wl  &  0377  ; 

minutes  =  (  time.wl  >>  8  )  &  0377  ; 

seconds  =  time.w2  &  0377  ; 

ticks  =  (  time.w2  >>  8  )  &  0377  ; 

if  (  StartHr  <  0  ) 

{ 

StartHr  =  hours  ; 

StartMin  =  minutes  ; 

StartSec  =  seconds  ; 

StartTic  =  ticks  j 

} 

tim  [  0]  =  (  hours  /  10  )  +  f0’  ; 

tim  [  1]  s  (  hours  %  10  )  +  'O'  ; 


tim  [  23  = 
tim  C  33  = 
tim  [  43  = 
tim  [  53  = 
tim  [  63  = 
tim  [  73  = 
tim  C  8]  = 
tim  C  93  = 
tim  [103  = 


f  •  f  • 

•  I 

(minutes  / 
(minutes  % 

i .  i  • 

•  I 

(seconds  / 
(seconds  % 

t  •  f  • 

(  ticks  / 
(  ticks  % 


10  )  +  »0* 

10  )  +  *0* 

10  )  +  ’0’ 
10  )  +  ’0’ 

10  )  +  »0» 
10  )  +  *0* 


return  ; 


->'« ».  *  *.  -v-r. 


j",  r 


T.. 


D.2.4  DispTime 

/ft***#***#*#**#######*#*#*#*#***##****#**###*#**********#*#*##*** 
*  * 


MODULE  NUMBER  /  NAME: 

1 

=t 

• 

X 

DispTime 

ft 

DATE: 

3  Nov  83 

« 

VERSION: 

A1 

« 

FUNCTION: 

Displays 

(upon  the  SOC  terminal 

« 

screen) 

current  system  time. 

* 

INPUTS: 

NONE 

« 

OUTPUTS: 

NONE 

« 

GLOBAL  VARIABLES  USED: 

NONE 

* 

GLOBAL  VARIABLES  CHANGED: 

NONE 

* 

GLOBAL  TABLES  USED: 

tim 

* 

GLOBAL  TABLES  CHANGED: 

NONE 

« 

FILES  READ: 

NONE 

ft 

FILES  WRITTEN: 

NONE 

« 

MODULES  CALLED: 

X  .3 

GetCurrentTime 

ft 

CALLING  MODULES: 

2 

Perf Normal Activities 

ft 

2.1  .1  - 

EvalSOCInput 

* 

3 

TermSystem 

« 

ft 

AUTHOR: 

Capt  Allan  F.  Masty.  GCS-83D 

» 

HISTORY: 

VSN  A1  - 

3  November  1983 

« 

* 

«•«*«*«*«*»*•«***«*«*••»*««« «*««*«« ««*•**•** *«****•«*••**• »«**«/ 


© 

DispTime  () 

{ 

int  k  ; 

GetCurrentTime  ()  ; 

for  (  k  =  0;  k  <  sizeof  (tim);  k++  ) 
printf  ("Jc",  tim  [k]  )  ; 
printf  (n\nn); 


return 


t 


D.2.5  CalcElapsedTime 

/*##***#********####**###*###*******#«#####***»***«#»######*»#*## 


MODULE  NUMBER  /  NAME:  X.5  -  CalcElapsedTime 


DATE: 

VERSION: 

FUNCTION: 

INPUTS: 

OUTPUTS: 

GLOBAL  VARIABLES  USED: 


GLOBAL  VARIABLES  CHANGED: 
GLOBAL  TABLES  USED: 

GLOBAL  TABLES  CHANGED: 
FILES  READ: 

FILES  WRITTEN: 

MODULES  CALLED: 

CALLING  MODULES: 


3  Nov  83 
A1 

Calculates  elapsed  time  from 
FEP  start-up  to  FEP  termination 
NCNE 
N(  NE 

h<  urs,  minutes,  seconds,  ticks, 
StartHr,  StartMin,  StartSec, 
StartTic 

hours,  minutes,  seconds,  ticks 

NONE 

NONE 

NONE 

NONE 

X.3  -  GetCurrentTime 

X.6  -  DispElapsedTime 


AUTHOR: 

HISTORY: 


Capt  Allan  F.  Masty,  GCS-83D 
VSN  A1  -  3  November  1983 


*•******••***»**•***««*»•«*•••*•*««««*«*•*»*********«*•*•«««***/ 


CalcElapsedTime  () 

{ 


int  k  ; 

GetCurrentTime  ()  ; 

if  (  (  ticks  -  =  StartTic  )  <  0  ) 

{ 

ticks  +=  60  ; 

— seconds  ; 

} 

if  (  (  seconds  -=  StartSec  )  <  0  ) 
{ 

seconds  +=  60  ; 

—minutes  ; 

} 

if  (  (  minutes  -=  StartMin  )  <  0  ) 
{ 

minutes  +=  60  ; 

--hours  ; 


rj  -  .  »  j - 


if  (  (  hours  -=  StartHr  )  <  0  ) 
hours  +=  24  ; 

return  ; 


D-6 1 


.*.*  V  V  V  W  *  *  *  •  •>  •  V*  ,%  .*•  -- 


D.2.6  DispElapsedTime 


/a*##***#******##****#*#*******##*******###*##**###*##*##*####**# 


*  * 

*  MODULE  NUMBER  /  NAME:  X.6  -  DispElapsedTime  * 

*  * 

DATE:  3  Nov  83  * 

VERSION:  A1  * 

FUNCTION:  Displays  (upon  the  SOC  terminal  * 

screen)  the  time  duration  * 

determined  in  CalcElapsedTime.  * 

INPUTS:  NONE  * 

OUTPUTS:  NONE  * 

GLOBAL  VARIABLES  USED:  NONE  * 

GLOBAL  VARIABLES  CHANGED:  NONE  * 

GLOBAL  TABLES  USED:  tim  * 

GLOBAL  TABLES  CHANGED:  tim  * 

FILES  READ:  NONE  * 

FILES  WRITTEN:  NONE  * 

MODULES  CALLED:  X.5  -  CalcElapsedTime  * 

CALLING  MODULES:  3  -  TermSystem  * 

* 

AUTHOR:  Capt  Allan  F.  Masty,  GCS-83D  * 

HISTORY:  VSN  A1  -  3  November  1983  * 


*  * 
ft*************************************************************** / 

DispElapsedTime  () 

{ 

int  k  ; 

CalcElapsedTime  ()  ; 

tim  [  0]  =  (  hours  /  10  )  +  ’O'  ; 

tim  [  1]  =  (  hours  %  10  )  +  ’O’  ; 

tim  [  2]  =  1 :  '  ; 

tim  [  33  s  (minutes  /  10  )  +  'O’  ; 

tim  [  4]  =  (minutes  %  10  )  +  'O'  ; 

tim  [  5]  =  •: ?  ; 

tim  [  6]  =  (seconds  /  10  )  +  ’O’  ; 

tim  [  73  =  (seconds  %  10  )  +  'O'  ; 

tim  [  8]  =  * : 1  ; 

tim  [  93  =  (  ticks  /  10  )  +  'O'  ; 

tim  [10]  =  (  ticks  %  10  )  +  '0*  ; 

for  (  k  s  0;  k  <  sizeof  (tim);  k++  ) 
printf  ("*c",  tim  [k]  )  ; 
printf  ("\nn); 

return  ; 


D.2.7  GatherStats 


/**************************************************************** 


MODULE  NUMBER  / 

NAME: 

X.7  -  GatherStats 

DATE: 

3  Nov  83 

VERSION: 

A1 

FUNCTION: 

Copies  node  queue  accounting 
information  to  file  LSIFEP.DAT 
for  off-line  data  reduction. 

INPUTS: 

p  =  pointer  to  char  array 

action  =  reason  for  call: 

1  r  entry  into  node 

2  =  exit  from  node 

OUTPUTS: 

NONE 

GLOBAL  VARIABLES 

USED: 

NONE 

GLOBAL  VARIABLES 

CHANGED: 

NONE 

GLOBAL  TABLES  USED: 

tim 

GLOBAL  TABLES  CHANGED: 

NONE 

FILES  READ: 

NONE 

FILES  WRITTEN: 

LSIFEP.DAT 

MODULES  CALLED: 

NONE 

CALLING  MODULES: 

2.1.2  -  MoveMsgtoNodeTTxDMA 

2.3.1  -  TTxtoDMAOutput 

2.3.2  -  DMAtoTTxOutput 

AUTHOR: 

Capt  Allan  F.  Masty,  GCS-83D 

HISTORY: 

VSN  A1  -  3  November  1983 

*  * 
ft*************************************************************** / 

GatherStats  (  p,  action  ) 

char  p[]  ; 

int  action  ; 

{ 

int  k  ; 

char  *c  ; 

GetCurrentTirae  (  )  ; 

for  (  k  s  0;  k  <  sizeof  (tim);  k++  ) 
putc  (  tim  [k],  fp  )  ; 

put c  ( *  * ,  f p  )  ; 

putc  (  action  +  ’O',  fp  )  ; 

putc  ( »  * ,  fp  )  ; 


for  (  c  =  0;  c  <  THTSIZE:  C++  ) 
put c  (  p  C  c  ],  fp  )  ; 

putc  (  »\015',  fp  )  ; 
put c  (  * \01 2  * ,  fp  )  ; 

return  ; 

} 


APPENDIX  E 

LSI  FEP  MEMORY  LOAD  MAP  (LSIFEP.MAP) 


This  is  the  baseline  Memory  Load  Map  for  th 
LSIFEX.SAV  executable  program  image. 


a^aaasHi^  , 


- '  -  *»  •  -  ‘  -  -M  ’/V  W.V.V.  n\ 


RT-11  LINK  V06.01B 

Load  Map 

Fri  07- 

Oct-83  00:00:00 

LSIFEX.SAV  Title: 

.MAIN. 

Ident : 

V04.00 

Section  Addr  Size 

Global 

Value 

Global 

Value 

.  ABS.  000000  001000 

(RW,  I, 

GBL, ABS, 

OVR) 

$SYSV$ 

000012 

$0HAND  001000  000252 

<RW,I, 

GBL, REL, 

CON) 

$0VRHV 

001000 

$OVRH 

001004 

V$READ 

001034 

V$D0NE 

001046 

$VDF5 

001234 

$VDF4 

001236 

$VDF1 

001246 

$VDF2 

001250 

$OTABL  001252  000160 

(RW,D, 

GBL, REL, 

OVR) 

001432  057052 

(  RW ,  I , 

LCL, REL, 

CON) 

SHELL 

001432 

SHELLX 

001452 

NXTARG 

002436 

SHLERR 

003016 

CLOSTD 

003066 

GETCHA 

003140 

PUTCHA 

003206 

GETS 

003442 

FGETS 

003706 

PUTS 

004206 

FPUTS 

004262 

FREOPE 

004342 

PRINTF 

004374 

FPRINT 

004424 

SPRINT 

004504 

OUTF 

004566 

OUTDEC 

005376 

OUTOCT 

005670 

STRCAT 

005772 

STRCMP 

006116 

STRCOM 

006256 

STRCOP 

006416 

STRCPY 

006520 

STRLEN 

006576 

ECHAR 

006646 

ENCHAR 

006656 

GCHAR 

006714 

INTASC 

006756 

ASCII I 

007102 

GETTIM 

007236 

AG1FL 

007506 

ECHO 

007510 

ENABLO 

007512 

LINE 

007514 

LINEPT 

007722 

OBPTR 

007724 

OBSIZE 

007726 

RARY1T 

007730 

STDERR 

007732 

STDIN 

007734 

STDOUT 

007736 

UCONLY 

007740 

CCSWIT 

007742 

CCMPY 

010006 

CCMULT 

010006 

CCDIV 

010114 

CCASR 

010344 

CCLRS 

010344 

CCLLS 

010366 

CCASL 

010366 

SETIDP 

010414 

ASTFN 

010426 

GETACH 

010756 

PUTACH 

010772 

INITIA 

011006 

ENTINT 

011022 

RETINT 

011052 

GTIME 

011076 

GAREA 

011172 

EXIT 

011176 

NODECH 

014140 

MAIN 

024000 

INITSY 

024026 

INITPS 

026246 

INITIN 

030174 

PERFNO 

030630 

SRVINP 

032276 

EVALSO 

033066 

MOVEMS 

033466 

BLDTRA 

034140 

SRVOUT 

034746 

SRVNOD 

035432 

E-2 


SYS$I  060504  000114 


SYS$S  060620  000004 


Segment  size  =  060624  = 


TTXT0D 

036556 

DMATOT 

037356 

TERMSY 

040176 

SOCINT 

040572 

T1 INTE 

041472 

T2INTE 

041656 

T3INTE 

042520 

T4INTE 

043362 

T5INTE 

044224 

T6INTE 

045066 

T7INTE 

045730 

DMAINT 

046572 

SETUPF 

050000 

ABORTF 

050350 

DMABUS 

050352 

DMAWC 

050354 

ENDIDX 

050356 

FILEOP 

050360 

FP 

050362 

GODMAF 

050364 

LASTMS 

050366 

NBTCHA 

050370 

NBT 

050372 

PSTCHA 

050422 

PST 

050424 

STARTI 

051414 

STOPID 

051416 

THT 

051420 

INCHAR 

051464 

OUTCHA 

055074 

(RW,I, 

LCL, REL, 

CON) 

$DIVTK 

060504 

$DIV60 

060532 

ISPY 

060576 

$GVAL 

060602 

(RW,D, 

LCL, REL, 

CON) 

$SYSLB 

060620 

$LOCK 

060622 

$CRASH 

060623 

:  12490. 

words 

Virtual  overlay  region  000001 


Partition 


000001  Segment  000001 


100002  006676 


Segment  size  =  006676  s 


(RW,I, 

DISPPSS 

GETCUR 

DISPELS 

GATHERS 

MINUTE 

STARTM 

STARTT 

TIME 

TICKS 

1759. 


LCL, REL, 
100002 
104242 
105234 
106256 
106606 
106612 
106616 
106622 
106642 
words 


CON) 

DISPNBS 

DISPTIS 

CALCEL 

HOURS 

STARTH 

STARTS 

SECOND 

TIM 


102540 

105112 

105736 

106604 

106610 

106614 

106620 

106626 


Virtual  overlay  region  000002 


Partition 


i  000002 

120002  013576 


Segment  000002 
( RW , I , LCL , R  EL , CON ) 


FOPEN  §  120010  FSIZE  120414 
FDELET  120416  FCLOSEg  120534 
GETC  @  133122  PUTC  @  133306 


Segment  size  =  013576  =  3007.  words 


Transfer  address  =  001432, 

High  limit  =  060622  s  12489.  words 


Virtual  high  limit  =  133576  =  23487.  words, 
next  free  address  =  140000 


Extended  memory  required  =  022500  =  4768. 


words 


APPENDIX  F 

LSI  FEP  USER'S  GUIDE 


This  Appendix  contains  detailed  information  on  the 
operation  of  the  LSI  FEP  system.  It  contains  sections 
describing  System  Initialization,  System  Operation,  System 
Termination,  and  Off-line  Accounting  Data  Reduction. 
Additional  reference  for  the  commands  recognized  by  the 
RT-11  monitor  can  be  found  in  the  RT-11  documentation  set 
[9] . 


F.1  System  Initialization  - 

The  steps  required  for  system  initialization  include 
Booting  the  RT-11XM  Monitor,  Setting  the  Date  and  Time,  and 
Starting  the  LSIFEP  Program  Image. 


F.1.1  Booting  the  RT-1 1 XM  Monitor  -  The  operator  places 
the  system  disk  (volume  ID  =  "RT11A")  into  the  leftmost  disk 
drive  of  the  Plessey  Peripheral  Systems  cabinet.  This  disk 
drive  (DYO:)  is  known  to  the  system  as  the  "system”  disk 
drive.  The  rightmost  disk  drive  ( DY 1 : )  is  known  to  the 
system  as  the  "user"  disk  drive.  The  operator  then  keys  in 
the  following  (upper  case)  command: 

DY<cr> 

where  <cr>  represents  the  "return"  key.  This  tells  the 
microcode  bootstrap  program  to  boot  the  system  from  device 
DYO.  When  the  boot  completes,  the  RT11SJ  monitor  will  be 
active.  To  boot  the  RT11XM  monitor  from  the  RT11SJ  monitor, 
type  the  command: 

© 

BOOT  RT1 1XM<cr> 

To  return  to  the  RT11SJ  monitor  from  the  RT11XM  monitor, 
type  the  command: 

BOOT  RT1 1 SJ<cr> 

At  anytime  during  operation,  the  operator  may  desire 
to  reboot  the  system  without  powering-down  and  powering-up 
the  Plessey.  This  can  be  accomplished  by  toggling  the 
"BOOT"  switch  on  the  front  Plessey  panel.  This  action  will 
result  in  the  microcode  bootstrap  loader  outputting  an 
asterisk  on  the  system  console  screen.  At  this  point,  the 


F-2 


above  boot  command  can  again  be  given.  The  contents 

of  disk  volume  ID  "RTIIA"  are  contained  in  Figure  F-1 . 


F . 1 .2  Setting  the  Date  and  Time  -  When  the  system  is 
first  booted,  no  date  will  be  known  to  the  monitor.  To 
remind  the  operator  to  set  the  date,  the  start-up  indirect 
command  files  for  both  monitors  ("STARTS. COM  and  STARTX.COM) 
contain  a  request  to  the  operating  system  to  display  the 
current  date.  This  command: 

DATE<cr> 

will  result  in  the  monitor  responding  with  the  message: 

?KM0N-W-No  Date 

At  this  point,  the  operator  should  set  the  date  by  an 
appropriate  command: 

DATE  l6-OCT-83<cr> 

Time  can  then  be  set.  First,  ensure  that  the  "LTCn 
switch  mounted  on  the  front  Plessey  panel  is  in  the  "ON" 
position.  This  switch  controls  the  Line  Time  Clock 
interrupt  hardware  feature.  Then,  issue  the  appropriate 
command: 


TIME  10:45:30<cr> 


16-Oct-83 
Volume  ID: 
Owner 


RT11A 

Masty 


PIP 

.SAV 

23 

09-Sep-80 

DUP 

.SAV 

41 

09-Sep-80 

DIR 

.SAV 

17 

09-Sep-80 

FORMAT 

.SAV 

19 

09-Sep-80 

RESORC.SAV 

15 

09-Sep-80 

SYSMAC 

.SML 

42 

0§-Sep-80 

MACRO  .SAV 

51 

09-Sep-80 

CREF 

.SAV 

6 

09-Sep-80 

LINK 

.SAV 

41 

09-Sep-80 

SRCCOM 

.SAV 

13 

09-Sep-80 

ODT 

.OBJ 

9 

21-Feb-80 

QUEUE 

.REL 

14 

09-Sep-80 

BATCH  .SAV 

26 

21-Feb-80 

BAX 

.SYS 

7 

04- Aug-83 

DXX 

.SYS 

4 

04-Aug-83 

DYX 

.SYS 

4 

04-Aug-83 

DMX 

.SYS 

5 

04- Aug-83 

MTX 

.SYS 

9 

04-Aug-83 

LPX 

.SYS 

2 

23-Dec-8l 

LSX 

.SYS 

2 

23-Dec-8l 

CRX 

.SYS 

3 

04-Aug-83 

NLX 

.SYS 

2 

04- Aug-83 

RT1 1XM.SYS 

102 

04- Aug-83 

SWAP 

.SYS 

25 

09-Sep-80 

IT 

.SYS 

2 

09-Sep-80 

DY 

.SYS 

4 

09-Sep-80 

RT1 1 SJ.SYS 

67 

09-Sep-80 

STARTS 

.BAK 

1 

02-Aug-83 

KED 

.SAV 

60 

09-Sep-80 

RUNOFF 

.SAV 

33 

1 0-Aug-8l 

DUMP 

.SAV 

8 

09-Sep-80 

LIBR 

.SAV 

22 

31-Mar-81 

SYSLIB. OBJ 

47 

13-Jul-81 

QUEMAN 

.SAV 

13 

21 -Feb-80 

ERROUT. SAV 

17 

21 -Feb-80 

CC 

.SAV 

95 

02-Nov-82 

STARTS.COM 

1 

26-Aug-83 

STARTX 

.BAK 

1 

l6-Sep-83 

STARTX.COM 

1 

16-Sep-83 

39  Files,  854  Blocks 
120  Free  blocks 


DYO:  Directory 


Image  - 


Disk  (volume 


F.1  .3  Starting  the  LSIFEP  Program  _ 

ID  =  "LSI  FEP  2")  contains  the  LSI  FEP  program.  The 
contents  of  this  disk  are  contained  in  Figure  F-2.  This 
disk  must  be  mounted  in  the  DY1  drive  and  the  following 
command  issued: 

RUN  LSIFEP<cr> 


The  * C*  Shell  responds  with  a  prompt: 


++ 

in  response  to  which  the  operator  will  key  a  carriage 
return.  Following  this  last  carriage  return,  the  ’C'  Shell 
releases  control  to  the  "main"  program  module  in  the 
LSIFEP. SAV  program.  After  program  initialization  has 
completed,  the  message: 

++++++++  FEP  Activated  at  10:46:15 

will  be  displayed  upon  the  system  operator  console. 

LSIFEP. SAV  is  a  program  image  which  can  be  run  using  the 
RT11SJ  or  RT11XM  monitor.  The  LSI  FEP  "2  disk  also  contains 
the  LSIFEX. SAV  program  image,  which  can  only  be  run  with  the 


RT11XM  monitor 


16-Oct-83 

Volume  ID:  LSI  FEP  #1 
Owner  :  Masty 


D 

.COM 

1 

28-Sep-83 

F  .COM 

1 

28-Sep-83 

X 

.COM 

2 

28-Sep-83 

C  .COM 

5 

28-Sep-83 

LSIFEX.MAP 

7 

07-Oct-83 

CH5  .RNO 

1 

03-Oct-83 

CH6 

.RNO 

1 

03-0ct-83 

FIG11  .RNO 

4 

03-0ct-83 

FIG31  . RNO 

4 

03-Oct-83 

FIG32  .RNO 

2 

04-Oct-83 

TABLET .RNO 

14 

04-0ct-83 

FIG21  .RNO 

3 

04-0ct-83 

A1 

.RNO 

25 

03-Oct-83 

TABLE2 . RNO 

4 

03-Oct-83 

A6 

.RNO 

1 

03-0ct-83 

A7  .RNO 

3 

03-Oct-83 

A8 

.RNO 

1 

03-0ct-83 

FIG41  .RNO 

6 

03-0ct-83 

B 

.COM 

1 

03-Oct-83 

CH4  .RNO 

32 

07-Oct-83 

CH3 

.RNO 

40 

1 2-0ct-83 

LFEPLO.C 

47 

12-Oct-83 

BIB 

.RNO 

1 1 

07-0ct-83 

A5  .RNO 

8 

07-0ct-83 

CH2 

.RNO 

74 

12-Oct-83 

A3  .RNO 

68 

07-0ct-83 

THESIS. RNO 

3 

12-Oct-83 

A2  .RNO 

23 

07-0ct-83 

CHI 

.RNO 

30 

12-Oct-83 

A4  .RNO 

50 

12-Oct-83 

30  Files, 

472 

Blocks 

502  Free  blocks 


Fig.  F-2 


DY1:  Directory 


F.2  System  Operation  - 


The  LSI  FEP  system  is  expected  to  function  with  no 
required  operator  control  or  maintenance  activity.  Three 
commands  have  been  implemented  for  operator  monitoring  of 
the  system  status.  These  commands  are  described  in  the 
following  paragraphs. 

F.2.1  NBT  -  The  status  of  the  Node  Buffer  Table  can  be 

displayed  by  issuing  the  command: 

NBT<cr> 

from  the  SOC  terminal  to  the  LSI  FEP  program.  The  format  of 
a  typical  Node  Buffer  Table  is  contained  in  Figure  F-3. 

F.2. 2  PST  -  The  status  of  the  Port  Status  Table  can  be 

displayed  by  issuing  the  command: 

PST<cr> 

from  the  SOC  terminal  to  the  LSI  FEP  program.  The  format  of 
a  typical  Port  Status  Table  is  contained  in  Figure  F-4. 

F.2. 3  TIME  -  The  current  system  time  can  be  displayed  by 

issuing  the  command: 


TIME<cr> 


from  the  SOC  terminal  to  the  LSI  FEP  program 


put 

get 

high 

0 

0 

1999 

2000 

2000 

3999 

LEGEND: 

i  =  index  into  NBT 
0  =  TTxDMA  node 
1  =  DMATTx  node 

low  s  NBT  [il.LowIdx 
put  =  NBT  [iJ.Putldx 
get  =  NBT  [i] .Getldx 
high  =  NBT  [ i] .Highldx 


i 

TID 

M 

I  .LOW 

I .  PUT 

I  .GET 

I . HIGH 

0.  LOW 

0.  PUT 

O.GET 

0. HIGH 

0 

soc 

L 

0 

4 

0 

199 

0 

0 

0 

199 

1 

T.1 

L 

200 

200 

200 

399 

200 

200 

200 

399 

2 

T.2 

L 

400 

400 

400 

599 

400 

400 

400 

599 

3 

T.3 

L 

600 

600 

600 

799 

600 

600 

600 

799 

4 

T.4 

L 

800 

800 

800 

999 

800 

800 

800 

999 

5 

T  .5 

L 

1000 

1000 

1000 

1199 

1000 

1000 

1000 

1199 

6 

T.6 

L 

1200 

1200 

1200 

1399 

1200 

1200 

1200 

1399 

7 

T.7 

L 

1400 

1400 

1400 

1599 

1400 

1400 

1400 

1599 

8 

DMA 

L 

1600 

1600 

1600 

1799 

1600 

1600 

1600 

1799 

LEGEND: 


i 

index  into  PST 

TID 

s 

Terminal  identification 

M 

- 

Terminal  Mode 

»L»  =  Line 

’  C’  =  Character 

I.  LOW 

_ 

PST 

[i].InLowIdx  (  InCha; 

I.  PUT 

s 

PST 

[ i]  .InPutldx 

I. GET 

- 

PST 

[ i] .InGetldx 

I. HIGH 

s 

PST 

[ i]  .InHighldx 

O.LOW 

s 

PST 

[ i] .OutLowIdx  (OutCha 

O.PUT 

S 

PST 

[ i] .OutPutldx 

O.GET 

PST 

C i ] .OutGetldx 

0 . HIGH 

PST 

[ i] .OutHighldx 

index ) 


index) 


Fig.  F-4  Port  Status  Table  (PST) 
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F.3  System  Termination  - 


The  system  can  be  terminated  in  an  orderly  manner  by 
issuing  a  control-C  (C)  from  the  SOC  terminal.  The  "CTRL" 
key  is  held  down  while  the  nCn  key  is  depressed.  This 
results  in  the  LSIFEP  program  restoring  interrupt  vector 
addresses  and  closing  the  LSIFEP.DAT  file  prior  to  returning 
control  to  the  monitor. 


F.4  Off-line  Accounting  Data  Reduction  - 

The  LSIFEP.DAT  file  is  created  during  each  run  of 
the  LSIFEP. SAV  program.  This  file  contains  the  accounting 
information  describing  the  data  movement  through  the  network 
nodes.  Each  line  in  the  file  contains  the  time  of 
recording,  a  movement  code,  and  the  message  Transport 
Header.  A  typical  LSIFEP.DAT  file  appears  in  Figure  F-5. 
Although  the  raw  data  file  is  produced,  time  did  not  allow 
the  generation  of  a  data  reduction  program  which  could 
process  this  file. 
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T.1L0 0020018 TTx 
T. 1 L0002001 8TTx 
S0CL0003  0020DMA 
SOCL00030020DMA 
T.5L00040020TTX 
T.5L00040020TTX 
SOCL0005001 8TTx 
S0CL0005001 8TTx 
T.7L00060058TTx 
T.7L00060058TTx 


LEGEND: 


record  format:  HH:MM:SS:TT  R  TID  M  NUMB  COUN  NOD 


HH  =  hours 
MM  =  minutes 
SS  s  seconds 
TT  =  ticks 


(2  chars) 
(2  chars) 
(2  chars) 
(2  chars) 


!  R  =  reason  for  statistics  gathering  (1 

1  s  entry  into  queue 

2  =  exit  from  queue 

I  TID  =  Terminal  Identifier  (3  chars) 


char) 


I  M  s  Terminal  mode 

i 

i 


NUMB  =  Message  Sequence  Number 


I 

i 

1 

I 

I 


COUN  =  Message  Character  Count 
NOD  =  Node  queue  ID 


(1  char  ) 
(4  chars) 
(4  chars) 
(3  chars) 


Fig.  F-5 


LSIFEP.DAT  File  Format 


Mt  % 


APPENDIX  G 

LSI  FEP  PROGRAMMER'S  GUIDE 


This  appendix  provides  software  documentation  for 
the  LSI  FEP  maintenance  programmer.  It  begins  by  describing 
the  LSI-11  source  code  edit  facility  —  the  Keypad  Editor 
[13].  It  then  proceeds  with  descriptions  of  the 
compilation,  assembly,  and  linking  processes.  Amplifying 
information  can  be  found  in  Chapter  4,  Appendix  C,  and 
Appendix  D. 


G.1  Editing  The  Source  Code  - 


The  PDP-11  Keypad  Editor  (KED)  was  used  to  create 
the  source  programs  during  this  implementation.  KED  is  used 
on  a  DEC  VT-100  terminal  and  requires  the  file  'KED.SAV'  on 


the  DYO:  disk  (  Fig  F-1  ).  KED  allows  use  of  the 

terminal’s  alphanumeric  keys  as  well  as  the  small  keypad. 
The  keypad  keys  activate  programmed  requests  for  cursor 
positioning,  text  deletion,  text  string  search,  and  other 
functions  described  in  DEC  documentation  [133. 

Activation  of  KED  is  accomplished  by  the  command: 

EDIT  LFEPLO. C<cr> 

where  <cr>  represents  striking  the  RETURN  key.  After  this 
command,  any  of  the  KED  directives  [133  can  be  issued. 


G.2  Compiling  The  Source  Code 


The  Telecon  *C’  compiler  was  used  to  compile  the  ’C’ 
language  source  code  into  RT-11  Macro-11  assembly 
instructions.  The  file  "CC.SAV"  must  exist  on  the  DYO: 
drive  [  fig  F-1  3.  The  ’C’  compiler  is  activated  by  the 
command : 


R  CC<cr > 

at  which  time  the  'C1  shell  prompt  appears: 


++ 


The  programmer  then  keys  the  input  ( * C *  source)  file  name 


and  the  output  (Macro-11)  file  name  [21;  233.  The  format  is 
as  follows: 

LFEPLO.C  >LFEPLO.MAC<cr> 

All  diagnostics  from  the  compiler  are  directed  to 
the  display  terminal  screen.  The  macro  file  which  is 
produced  as  output  may  be  several  times  the  size  (disk 
blocks)  of  the  input  *  C *  text  file.  To  ensure  a  large 
contiguous  disk  area  for  the  macro  file,  it  is  sometimes 
necessary  to  "SQUEEZE"  the  DY 1 :  disk  prior  to  invoking  the 
f C ’  compiler.  The  format  for  the  squeeze  command  [9:4.1673 
is  as  follows: 


SQUEEZE/NOQUERY  DY1:<cr> 


G.3  Assembling  The  Macro  File  - 

The  PDP-11  Macro  Assembler  [153  was  used  to  produce 
the  object  modules.  Input  to  the  assembler  consists  of 
macro  files  containing  the  PDP-11  assembly  instructions 
[20:53-1623.  The  format  [9:4.1283  of  the  macro  command  is: 

MACRO  LFEPL0<cr> 


This  command  specifies  an  input  file  of  "LFEPLO.MAC"  (  .MAC 


is  default  file  type)  and  an  output  file  of  "LFEPLO.OBJ"  ( 
default  file  type  is  .OBJ  while  default  file  name  is  same  as 
the  input  file  name). 


G.4  Linking  The  Object  Modules  - 

So  far,  the  documentation  has  only  addressed  the 
programming  issues  for  one  program  (  LFEPLO.C  )  through 
edit,  compile,  and  assembly.  Any  functions  and  data  items 
that  could  not  be  found  by  the  compiler  during  compilation 
were  treated  as  external  references  which  would  be  supplied 
later.  The  macro  assembler,  likewise,  deferred  action  on 
these  externals  and  passed  on  the  object  file  with  these 
externals  still  undefined.  The  linker,  however,  requires 
all  references  to  be  resolved  before  it  can  create  the  .SAV 
executable  program  image  file.  Therefore,  it  is  at 
this  stage  that  all  the  pieces  [  para  4.3  3  of  the  LSIFEP 
(or  LSIFEX)  system  are  brought  together.  Two  indirect 
command  files  [9:4.93  have  been  created  to  accomplish  the 
linking  function.  These  indirect  command  files  exist  on  the 
DY1 :  disk  [  fig  F-2  ]  as  "F.COM"  (creates  "LSIFEP. SAV”)  and 
"X.COM"  (creates  "LSIFEX. SAV") .  When  all  the  ".OBJ"  files 
have  been  created,  the  "F.COM"  file  can  be  invoked  using  the 


command : 


eF<cr> 


The  RT-11  monitor  then  executes  the  commands  within 
the  "F.COM"  file.  The  file  contents  are  shown  in  Figure  G-1 
for  "F.COM"  and  Figure  G-2  for  "X.COM".  The  output 

of  the  "F.COM"  file  consists  of  the  "LSIFEP.SAV"  executable 
image  and  a  text  file  "LSIFEP.MAP"  which  shows  the  memory 
mapping  produced  by  the  linker.  The  contents  of 
"LSIFEX.MAP"  is  contained  in  Appendix  E.  Execution 

instructions  for  the  executable  images  are  contained  in 
Appendix  F. 


This  indirect  command  file  is  F.COM 
It  is  used  to  invoke  th  RT-11  Linker. 

F.COM  is  invoked  by  typing  @F 

at  the  console  keyboard.  I 

The  following  files  must  be  defined 
prior  to  invoking  the  linker: 

LFEPIO. OBJ 
LFMLLO.OBJ 
LFMLHI.OBJ 
NBUFF.OBJ 
LFEPHI . OBJ 
LFEPLO.OBJ 
TBUFF.OBJ 

The  linker  creates  two  files: 

LSIFEP.SAV 
LSIFEP.MAP 


r  link 

lsifep,  lsifepslfepio,  lfrullo,  lfmlhi ,  nbuf  f// 
If ephi , If eplo , tbuf f// 

A  n 


’F.COM*  Indirect  Command  File 


!  This  indirect  command  file  is  X.COM  - 

!  It  is  used  to  invoke  the  RT-11  Linker. 

!  X.COM  is  invoked  by  typing  @X 

l  at  the  console  keyboard. 

!  The  following  files  must  be  defined 
!  prior  to  invoking  X.COM: 

!  The  commands  forwarded  to  the  Linker  will  create 
!  an  extended  memory  LSIFEX.SAV  file  which 

1  can  be  run  on  an  LSI-11/23  using  the 


RT1 1 XM 

extended 

memory  monitor. 

LFEPIO. OBJ 

linked 

to 

low 

memory 

LFMLLO.OBJ 

— 

linked 

to 

low 

memory 

LFMLHI.OBJ 

- 

linked 

to 

high 

memory 

NBUFF.OBJ 

- 

linked 

to 

low 

memory 

LFEPHI . OBJ 

— 

linked 

to 

high 

memory 

LFEPLO. OBJ 

- 

linked 

to 

low 

memory 

TBUFF.OBJ 

- 

linked 

to 

low 

memory 

!  The  linker  creates  two  files: 

! 

!  LSIFEX.SAV 

!  LSIFEX . MAP 

r  link 

lsifex,lsifex=lfepio, lfrallo,nbuff , lfeplo, tbuff// 
lfephi/V: 1 
lfmlhi/V: 2// 

AC 


’X.COM'  Indirect  Command  File 
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